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© An ATM switch with multicast capability is pro- 
vided that internally uses input and output identifiers 
to identify the cell input and output streams, the 
relevant input identifier being generated for each cell 
as it arrives. The apparatus stores both the cell 
bodies of the cells received by the input means and 
a respective sequence data set (65) for each input 
stream. Each sequence data set serves to order 
ute ceil bodies reccivso tor tne corresponding inp^t 
stream in order of receipt. The sequence data sets 
(65) are heid in a queuing block (63) that includes an 
input control (66) which upon a new cell body being 
stored, updates the sequence data set (65) of the 
input stream to which the cell belongs as identified 
by the corresponding Input identifier. The queuing 
block (63) also has an output control (69) for main- 
taining for each output stream a sequence position 
indicator (68) referencing into the sequence data set 
(65) of the corresponding input stream to indicate 
the next cell body to be sent on the output stream 
concerned. A scheduling block (75) of the apparatus 
outputs the output identifier of the output stream on 
which a cell is next to be output. This identifier is 
used by the output control (69) of the queuing block 
(63) to look up the corresponding sequence positioin 
indicator (68) which it uses, in turn, to reference into 
the corresponding sequence data set (65) thereby to 



output stream. The same queuing arrangement can 
also be used in systems handling variable-length 
packets. 
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The present invention relates generally to mul- 
ticasting apparatus for multicasting packets (includ- 
ing fixed-length packets or "cells"); in particular, 
but not exclusively, the present invention relates to 
an ATM switch with cell multicasting capability. 

ATM (Asynchronous Transfer Mode) is a mul- 
tiplexing and switching technique for transferring 
data across a network using fixed sized cells that 
are synchronous in the sense that they appear 
strictly periodically on tho physical medium. Each 
cell comprises a paytoad portion and a header, the 
latter including a label that associates the cell with 
an instance of communication between sending 
and receiving network end systems; this instance 
of communication may involve the transfer of many 
cells from the sending end system, possibly to 
multiple receiving end systems. ATM is asynchro- 
nous in the sense that cells belonging to the same 
instance of communication will not necessarily ap- 
pear at periodic intervals. 

In ATM, the labels appended to the cells are 
fixed-size context dependent labels, that is, they 
are only understandable in the light of context 
information already established at the interpreting 
network node, the label generally being replaced at 
one node by the label required for the next node. 
In other words, ATM is a virtual circuit technology 
requiring a set up phase for each instance of 
communication to establish the appropriate label 
knowledge at each node. 

ATM technology is finding increasing popular- 
ity because it can offer an acceptable compromise 
in combining timeliness characteristics (normally 
associated with circuit switching technologies) and 
statistical advantage (associated with packet 
switching technologies). ATM holds out the pros- 
pect of a single transfer mode technology for carry- 
ing all traffic types, including voice, entertainment 
services, or computer traffic. 

Tzz crcccr.; .r.vcnSGii is epy"C£<:ve oe^e^vy to 
AT^ cystsrr.s other systems) independently 
of specific implementation details such as eel! size 
and reference to ATM in the accompanying claims 
should be accordingly interpreted. However, in the 
following description; particular reference will be 
made to the emerging B-ISDN ATM standards be- 
ing evolved by the CCITT and the ATM Forum (the 
former being primarily concerned with public net- 
works and the latter with computer-related user 
networks). 

In fact, even within these emerging standards, 
the semantics of the information contained in the 
header portion of each cell varies depending on 
where in the network tho cell appears (at its edge 
or internally), and the nature of the overlying ATM 
adaption layer which processes ATM cells in the 
network end systems. Unless specifically stated 
otherwise, in the following description the cell for- 



mat under consideration is the B-ISDN UNI (User 
Network Interface) cell format for AAL5 services 
("AAL" refers to the ATM Adaption Layer, AAL5 
being a connection oriented, variable bit rate asyn- 

5 chronous communication service appropriate to 
computer communication). 

Figure 1 of the accompanying drawings shows 
the format of such a cell in a byte wide format. As 
can be seen, the cell is made up of a 5-byte 

?o header and a 48-byte payload of user data. The 
header fields are as follows: 

- GFC 4 bits General Flow Control Field; 

- VPI 8 bits Virtual Path Indicator field; 

- VCI 16 bits Virtual Channel Indicator field; 
75 - PT 3 bits Payload Type Field; 

- EOP 1 bit End of Packet Field; 

- HEC 8 bits Header Error Check Field; 

The VPI and VCI together form the virtual 
circuit label for the cell on a particular link and this 

20 label forms the basis on which the cell is routed at 
the next network node it encounters. Generally, in 
ATM parlance, a virtual circuit is called a "Virtual 
Channel" and the VPI fields can be thought of as 
identifying a group of virtual channels on a link 

25 whilst the VCI identifies a particular virtual channel 
in that group. 

The EOP bit is used to indicate that the cell is 
the last cell of a sequence of cells that together 
make up a higher level application data unit (pack- 

30 et). The advantage of giving this end of packet 
information visibility in the cell header, is that it 
enables all the cells making up a packet to be 
discarded if one constituent cell is lost. 

An ATM cell arriving at a network node through 

35 one port will be re-routed (or switched) according 
to the VPI and VCI information stored in the cell 
header and the context information established in 
the node at set up time. The VPI and VCI informa- 
tion wi!! be changed and the ce!! output. Such a 

<o r.zcz :c gcr.crsiiy referred *c £3 £Ti ATm Switch 10 
and conceptually comprises an N-port switch core 
that is responsible for carrying out tiie following 
operations on the cells it handles: 

- determining which cell belongs to which 
45 channel; 

- deciding what channel a cell is destined for 
and routing it there; and, 

- arbitrating among demands for access to the 
appropriate output port. 

so The switch will also include some sort of a proces- 
sor unit for looking after channel set up and any 
management functions, and interface circuitry for 
interfacing the switch core to the links connected 
by the switch, these links connecting to respective 

55 external ports of the switch. 

The switch core is generally designed to have 
a high bandwidth and this enables the switch to be 
used to service a plurality of links that are either 
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inherently or statistically of tow bandwidth, these 
links being first multiplexed together before being 
fed to the switch core. Conversely, the output of 
the switch core is demultiplexed for passing to the 
appropriate link. 

Figure 2 shows a known form of ATM switch in 
which a common memory is used to temporarily 
store all the cells passing through the switch. More 
particularly, a number of input links 4 are con- 
nected to a multiplexer 1 which feeds a switch core 
2; the switch core in turn outputs cells to a de- 
multiplexer 3 where they are distributed to the 
appropriate output link 5. Generally, the input and 
output links 4, 5 are paired. 

The multiplexer cyclically passes a cell from 
each input link 4 to the switch core 2. Each cell is 
split by splitter 6 into its header which is passed to 
a header converter 10 via line 7, and the cell body 
which is output from the splitter on line 9. 

The header converter 10 examines the 
VPI + VCI information contained in each header to- 
gether with input link identity information passed to 
it over line 8 from the multiplexer 1 . On the basis 
of this information, the header converter 10 gen- 
erates a new header with an appropriate VPI + VCI 
and passes this header on line 11 to a combiner 12 
to which the line 9 carrying the cell body is also 
connected. The combiner 12 then recombines the 
cell header and body and stores the cell in a 
common memory 13 at an address which is output 
on line 14. For each ouput link, a corresponding 
output queue 16 is maintained in the switch core. 
As each cell is stored in the common memory, the 
corresponding address is passed to the output 
queue 16 appropriate for that cell, the identity of 
this output queue being supplied over line 15 from 
the header converter to cause the address to be 
stored in the correct queue. 

The de-multiplexer 3 cyclically queries the out- 

ZJt CuGuo "?o 0*6*- ' ' tC each output 

queue ;r. turn to oulpul ihe address of tne next ceil 
intended for the corresponding output link. The 
address output from each queue is fed by line 18 
to the common memory 13 to cause the cor- 
responding cell to be output cn line 19 to the de- 
multiplexer 3. The de-multiplexer then directs the 
cells to the appropriate output link 5. 

One problem with this simple architecture is 
that it is not well adapted for multicasting, that is, 
where a cell is to be output on a number of 
different output links. For example, if multicasting is 
achieved by having the address of a cell stored in 
all of the appropriate output queues, then not only 
does it result in the cell address being stored 
several times, but it is not easy to implement a 
mechanism to ascertain when a particular cell has 
been output on all the intended links. 



A further disadvantage of the Figure 2 arrange- 
ment is that the cells intended for the cell output 
link are treated on a First-ln/Ftrst-out basis with 
respect to the output queues concerned. 

5 An improved implementation of ATM switch is 

the Xunet switch described in "A High-Performance 
Queuing Engine for ATM Networks" (International 
Switching Symposium, 1992, C.R. Kalmanek, S.P. 
Morgan, and R.C. Restnick III). In this switch, each 

70 output port has its own memory area to which are 
fed the cells to be output on output streams asso- 
ciated with the port. However, the cells supplied to 
an output port are not treated on a First-In/First-Out 
basis but are, instead, scheduled according to 

75 some priority scheme. More particularly, each out- 
put port has 32k output queues which are perma- 
nently present and are used as required to store 
cells associated with the same output stream, that 
is. with the same VPI/VCI combination. Each queue 

20 has a designated queue number QN and these 
queue numbers are formed into 16 different priority 
lists. Each queue number only appears once in all 
of the priority lists. A scheduler, in determining 
which cell to send next, looks at the priority lists 

25 and takes the queue number that is at the head of 
the list of the highest priority list with something in 
it. This queue number is then used to access the 
corresponding cell queue and the cell at the head 
of that queue is then output. The queue number is 

30 then recirculated back into the priority lists though 
it may, or may not, be returned to the same list 
from which is was taken. 

The Xunet switch provides for flexible schedul- 
ing. However, in relation to multicasting, it causes 

35 each cell that is to be multicast to be replicated a 
corresponding number of times together with asso- 
ciated control data. 

Summsry of ths ! ft vender. 

to 

According to one aspect of the present inven- 
tion, there is provided apparatus for receiving at 
least one input stream of packets each having a 
packet body and multicasting this stream as a 
45 plurality of output streams of packets by copying 
across the packet bodies of the packets of the 
input stream into packets of the output streams, the 
apparatus comprising: 

- input means for receiving packets and deter- 
so mining to which input stream each packet 

belongs, 

- storage means for storing both the packet 
bodies of the packets received by the input 
means and a respective sequence data set 

55 for each input stream, each sequence data 

set serving to order the packet bodies re- 
ceived for the corresponding input stream in 
order of receipt, the storage means including 
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- the packet bodies are each stored only once 
in the storage means, 

- the sequence data sets together have a re- 
spective entry for each packet body, each 
entry including a pointer to the corresponding 
packet body, and each entry being present 
only once in the sequence data sets taken 
together, and 

- each output stream is identified in the ap- 
paratus by a respective output identifier and 
the output means includes send-contro! 
means for effecting output scheduling on the 
basis of the output identifiers, each identifier 
being actively present no more than once at 
any one time in the send-control means. 

The present invention is particularly suited to 
the implementation of multicasting ATM switches 
(each packet then being a fixed-length cell). 

Brief Description of the Drawings 

An ATM switch embodying the invention will 
now be particularly described, by way of non- 
limiting example, with reference to the accompany- 
ing diagrammatic drawings in which: 

- Figure 1 is a diagram of the format of a 
standard ATM UNI cell for an AAL5 connec- 
tion, this Figure constituting prior art and hav- 
ing already been discussed above; 

- Figure 2 is a diagram of a general ATM 
switch architecture in which low speed links 
are first multiplexed together before being fed 
to a port of the ATM switch core, this general 
architecture being known and having been 
already discussed above; 

- Figure 3 is a top-level diagram of the ATM 
switch embodying the invention; 

- Figure 4 is a block diagram of a switch core 
block of the Figure 3 switch; 

- Flg-jre 5 is r, ??t-'e depicting z zzr**zz ioia vo>- 
tne switch ccpg ports. 

- Figure 6 is a block diagram of an adaptor 
card of the Figure 3 switch. 

- Figure 7 is a table depicting a service rota for 
the external switch ports of the Rgure 6 
adaptor card; 

- Figure 8 is a functional block diagram of a 
controller of the Figure 4 switch core block; 

- Figure 9 is a diagram illustrating port queues 
kept by a scheduler of the Figure 8 controller; 

- Figure 10 is a diagram of a master VCN 
lookup block of the Figure 8 controller; 

- Figure 11 is a diagram illustrating two meth- 
ods for dropping an AAL5 connection cell 
upon a cell of the packet being dropped; 

- Figure 12 is a diagram of data structures 
used to implement various lists and queues 
in a cell-details queuing block of the Figure 8 



controller; 

- Rgure 13 is a diagram illustrating the addition 
to an input cell-stream list of the details of a 
newly arrived cell; 

5 - Rgure 14 is a flow-chart illustrating the op- 
eration of an output control of the queuing 
block of the Rgure 8 controller; 

- Rgure 15 is a diagram illustrating the pur- 
pose and effect of the stop bit included in 

10 each cell-details entry of the lists and queues 

maintained in the queuing block; 

- Rgure 16 is a diagram of data structures for 
implementing a multicast expander of the 
Rgure 8 controller; 

75 - Rgure 17 is a diagram illustrating an im- 
proved implementation of the Figure 16 data 
structures; 

- Figure 18 illustrates a credit bucket rota table 
maintained for guaranteed bandwidth ser- 

20 vices; 

- Rgure 19 is a diagram illustrating the opera- 
tion of an eligibility control block of the Figure 
8 controller; 

- Rgure 20 show a service rota operated by 
25 the eligibility control block; 

- Figure 21 is a diagram of data structures 
used in a scheduling block of the Figure 8 
controller; 

- Figure 22 is a functional block diagram of the 
30 Figure 8 controller but with the functional 

block boundaries changes as compared with 
Figure 8; and 

- Rgure 23 is a functional block diagram simi- 
lar to Figure 22 but showing a variant of the 

35 controller. 

Best Mode for Carrying out the Invention 

Architectural Overview 

<c 

The ATM switch to be described hereinafter 
has a high-bandwith, N-port, switch core to which 
low-speed links are interfaced via multi- 
plexer/demultiplexer units associated with respec- 
ts tive switch core ports. The switch core services its 
ports cyclically to take in new cells for processing 
one at a time; there are thus two levels of mul- 
tiplexing/de-multiplexing embodied in the architec- 
ture (except, of course, when N = 1). 
50 Referring more specifically to Figure 3, at the 

top level the switch embodying the invention can 
be thought of as consisting of three main types of 
blocks. At the centre there is the N-port switch core 
20, each switch core port 21 operating at the same 
55 predetermined speed of, for example, 622Mb/s. 
Attached to each of the ports 21 is an adapter card 
22. Each adapter card 22 interfaces a number of 
tower speed external switch ports 23 to a switch 
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core port. Finally there is the processor board 24, 
which performs the signalling and virtual channel 
setup functions. 

To give specivity to the switch description, the 
switch core ports are taken as operating at 622 
Mb/s ; however, it will be appreciated that this port 
speed is not critical to the present invention, higher 
and lower speeds being possible. 

The architecture of the switch is a "shared 
everything" architecture. This means that there are 
no substantial resources dedicated to any particular 
port and buffering and intelligence are centralized. 
Thus the Adapter Cards contain almost no buf- 
fering and intelligence. 

A common master clock 25 feeds clock signals 
to all three main switch blocks (switch core 20, 
adaptor cards 22, processor 24) and local slave- 
clock units 26 generate appropriate local clock 
signals; this arrangement ensures that the clock 
speeds have a constant predetermined relationship. 
A line 27 provides a global synchronising signal 
from the processor block 24 to the switch core 20 
and adaptor cards 22 to synchronise operation of 
the blocks at start up. 

The following three subsections describe each 
of the three above referred to main blocks in more 
detail. 

N-Port Switch Core 20 - 

A block diagram of the N-port Switch Core 20 
is shown in Figure 4 and, as can be seen, the 
switch core comprises a switch fabric 30 with input 
and output ports 37, 38 which are generally paired 
and as such constitute the switch core ports, a 
shared cell-body memory 31, a free address list 
memory 32, a controller 33, and a communications 
block 34 for carrying out ATM adaption layer and 
other higher communication layers processing of 
oe!!s interred fn? • ccrr^s frcrr. tr.c CGiTUoiie** 
(thereby enabling tu8 ?5»er io ccrr.rr.unjcata over 
the network of which the switch forms a part) 

At this level of abstraction, operation of the 
switch core is very simple. The N input ports 37 
are serviced in strict order one cell at a time. When 
a cell comes in on one of the input ports the Fabric 
30 writes the cell body into the Shared Cell Body 
Memory 31 at an address taken from the free 
address list memory 32. This address is also 
passed to the Controller 33, along with the header 
of the cell to which it relates. Because the input 
ports 37 are serviced in a fixed order, the Control- 
ler 33 can tell the source of the cell from the arrival 
time of the header. 

The controller 33 stores and processes the 
headers and cell body addresses of incoming cells. 
It also makes decisions about which cell to send 
next on each output port 38 based on the queueing 



mode! and scheduling policies (to be described 
hereinafter). To send a cell the controller outputs 
the cell's header and the address at which the 
celPs body is stored. The fabric 30 reads the cell 

5 body out of the Shared Cell Body Memory 31, 
combines it with the header and sends the cell on 
an output port. As the output ports are also ser- 
viced in a fixed order, the destination of the cell is 
determined by the time at which the controller 

10 sends the header and address. As well as the main 
switch core ports (input/output port pairs 37,38) to 
which Adapter Cards 22 attach, the Fabric 30 also 
supports two slower ports. One of these ports 39 is 
used by the processor 24 to send and receive 

15 cells, the other is used by the controller to send 
and receive flow control cells via the unit 34. 

The bandwidth of the Shared Cell Body Mem- 
ory 31 and the Controller 33 is sufficient to accom- 
modate receiving cells from all the input ports 37 

20 and sending cells to all the output ports 38 at the 
maximum rate of these ports. The clocking of the 
constituent elements of the switch core 20 is con- 
trolled by the local clock unit 26. 

Considering the timing of switch core operation 

25 in more detail, if the period between successive 
cell arrivals at the given main switch core port 
speed (622 Mb/s) is T, then for an N-port switch 
core, the fabric 30 must be capable of receiving N 
cells in each period T, that is, one cell from each 

30 main switch core input port 37 . Similarly, the fabric 
must be capable of sending N cells in period T, 
that is, one cell for each output port 38. The fabric 

30 must also be able to handle the transfer of cells 
through the processor and controller ports. 

35 The fabric basically comprises a plurality of 

shift registers into and out of which cells are trans- 
ferred, by shifting, through the main switch ports, 
these transfers going on at the same time for all 
ports; the transfer of ceil body -ats betwee- f*e 

<o cn:ft roglstetS o? the isonc 30 and the shsrec! 
memory 31 and of the cell headers to/from the 
controller 33 is then done by parallel transfer 
from/to the shift registers according to a predeter- 
mined cycle of transfers that deal with each port in 

45 turn. 

The general process involved for each cell 
transferred in through a switch core port is thus 
that the cell header is first shifted into the fabric 
followed by the cell body; whilst the cell body is 

so being shifted in, the cell header is transferred out 
to the controller and then during the subsequent 
transfer of the cell body to the memory 31, the 
header of the next ceil for the port concerned is 
shifted into the fabric. As similar but opposite pro- 

55 cess is followed to output a cell. 

So far as the transfers to the cell body memory 

31 are concerned, the transfer cycle simply goes 
round each main switch port in turn (for example, if 
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there are four input ports 37 and four output ports 
38, the transfer cycle might first service each input 
port in turn transferring cell body data to the mem- 
ory 31, and then service each output port in turn, 
transferring data from the memory 31 to the fabric). 
The transfer of cell body data between the memory 
31 and the shift registers associated with the con- 
troller and processor ports is handled by the fabric 
in predetermined redundant portions of the cell 
transfer cycle for the main switch core ports. 

The transfer of cell headers between the fabric 
30 and the controller 33 may follow a similar trans- 
fer cycle as for the cell body transfers provided 
that the controller 33 receives and can output 
headers sequentially (the controller effecting its 
processing sequentially). Thus, the controller and 
processor ports must be allocated their own slots 
in an overall port service cycle followed by the 
controller. Of course, the controller and processor 
ports are not serviced as frequently as the main 
switch core ports and generally, if the processor 
and controller ports run at 1/n ,h of the speed of the 
main ports, then the processor and controller ports 
will be serviced only once every n services of the 
main ports. The result is an overall port service 
cycle such as illustrated in Figure 5 for a switch 
core having four main ports P1 to P4, this cycle 
applying both to the input of headers to the control- 
ler 33 and to the output of headers from the 
controller (in fact, the cycles need not be the same 
for input and output, but generally this will be the 
case). 

The cell headers passed to the controller 33 
are associated with their corresponding cell bodies 
by the addresses that are used to store the cell 
bodies in the memory 31, these addresses being 
stored with the header data in the controller 33. It 
will be appreciated that the address at which a cell 
body is stored must be supplied to the controller 
33 at a timing appropriate tc ensure *s stored 
tr.z correct usaticr. 

As is explained hereinafter, certain of the ceils 
supplied through the main switch core ports may 
be empty cells (or, more precisely, cells that are to 
be ignored), this condition being indicated by the 
values of VPI and VCi being set to zero in the cell 
header. The presence of such a ceil does not alter 
the process of transferring the cell body to the 
memory 31 or cell header to the controller 33; 
however, upon the controller 33 finding that the VPI 
and VCI of the cell header are zero, it simply 
passes the associated address at which the cell 
body has been stored, back to the free address list 
32, it being unnecessary to take ay action in the 
memory 31 itself. 



Adapter Card 22. 

Each Adapter Card combines a number of ex- 
terna! input/output port pairs into one switch core 

5 port. The externa! input/output ports on one Adapt- 
er card may consist of any combination of links 
provided the bandwidth of these links sums to less 
than the switch core port speed. For instance, if the 
switch core port speed is 622Mb/s, an Adapter 

io card might contain twelve 51Mb/s ports, or four 
155Mb/s ports or a mixture of speeds such as 
three 155Mb/s, one 100 Mb/s and one 51Mb/s port. 

The Adapter Card's operation is very simple. 
For the most part it does not look at the cells it 

is handles. One exception to this is the Header Error 
Check (HEC) field of each cell, which is generated 
by the Adapter Card for cells going out and 
checked by the Adapter Card for cells coming in. If 
the HEC fails for an incoming cell then the Adapter 

20 Card turns the cell into an empty cell by setting the 
VPI and VCI fields of the cell to zero. 

An example of an Adapter card 32 is shown in 
Figure 6 which is intended to interface five external 
low-speed ports A to E to one switch core port. 

25 Only the port A components are shown for reasons 
of clarity. The adaptor card 22 comprises the fol- 
lowing elements: 

- a respective physical layer/framer unit 40 for 
each port A to E. The units 40 carry out the 

30 header error check functions mentioned 

above. 

- a small (two cell) input FIFO 41 for the input 
side of each port A to E; these FIFOs help to 
match the rates of the input ports to the 

35 switch core port. 

- a respective unit 42 for detecting when the 
contents of a corresponding one of the input 
FIFOs 41 falls below an amount equal to one 
cell. 

-a zrr.z:: cirtpui FIFO 43 for the cjtcidc Side o? 
each port A to E; these FIFOs help to match 
the rate of the switch core port to that of the 
output ports. 

- a respective unit 44 for detecting when the 
45 contents of a corresponding one of the output 

FIFOs 43 exceeds an amount corresponding 
to one cell. 

- a Time Division Multiplexer 45 which multi- 
plexes cells form each of the input ports into 

so a switch core input port 37. Cells are sent 

cyclically in a predetemined port order (dis- 
cussed below) that is held in an input port 
rota unit 46; the start of the port rota cycle is 
dictated by the global synchronisation signal. 

55 - a Time Division Demultiplexer 47 which takes 
cells from the corresponding switch core out- 
put port 38 and sends them to the appro- 
priate output port A to E. Cells arrive in a 
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predetermined order that is held in a prog- 
rammable output port rota unit 48 that is 
synchronised to the global synchronisation 
signal. 
• a local clock unit 26. 
Due to the close functional association of the 
multiplexer 45 and demultiplexer 47 on the one 
hand, and the associated switch core port on the 
other, the multiplexer 45 and demultiplexer 47 are 
clocked by clocking signals supplied from the 
switch core port to provide synchronised transfer of 
cells to/from the switch-core fabric 30, 

The switch core port is run at a speed slightly 
greater than the cumulative speeds of the external 
ports associated with it (the output side of these 
latter ports being clocked from the local clock unit 
26 which is set accordingly). One reason for doing 
this is to accommodate variation in the actual 
speed of the links connected to the external ports 
from their nominal values. This overrunning of the 
switch core port means that the input FIFOs 41 are 
being emptied faster than they are being filled. To 
deal with this, whenever the contents of one of the 
FIFOs 41 fall below an amount corresponding to 
one cell, the associated unit 44 signals the mul- 
tiplexer 45 causing an empty-cell insertion unit 49 
to generate and send an empty cell to the control- 
ler 33 in the appropriate time slot; this allows the 
input FIFO to fill again. 

Conversely, the output FIFOs 43 are being 
filled faster than they can be emptied. This is 
handled by the appropriate unit 44 on detecting 
that the contents of its associated output FIFO 43 
is more than one cell, providing a corresponding 
indication to the controller 33. If this indication is 
present upon the controller 33 preparing to send a 
cell to the corresponding external port, then the 
controller will send an empty cell instead to the 
external port. A unit 50 of the demultiplexer 47 Is 
cLTangod to detect end tziztz tr.lc crr.p^ ce;; al- 
lowing the FIFO 43 to ci^r?. 

Considering next the order of servicing of the 
external ports as established by the port rotas 
stored in units 46 and 48, clearly the higher speed 
ports will need servicing more frequently than the 
lower speed ones. In genera! terms, the cell period 
of the lowest speed port sets the overall cycle time 
of the port rota, this lowest speed port only need- 
ing to be serviced once during the cycle whilst the 
higher speed ports will need servicing two or more 
times. Figure 7 illustrates a possible port rota for 
the Figure 6 adaptor card. During each cell period 
T of the associated switch core port, one cell is 
transferred to/from the switch core port from/to the 
external port A to D next on the port rota. 



Processor 

The processor unit 24 performs virtual channel 
connection setup and management, by receiving 

5 requests for connections and manupulating data 
structures in the controller 33. The processor also 
initialises controller data structures at power up. 

To accomplish these functions the processor 
unit 24 has two interfaces to the switch core. The 

70 first is a cell interface through the processor input 
and output ports of the switch fabric; this allows the 
processor to send and receive cells, just as it 
would be able to do were it attached to one of the 
input/output ports on an adapter card. 

75 The second interface is directly with the con- 

troller itself (see Figure 4) to allow the processor to 
access internal data structures in the controller, so 
that it can set up and modify virtual channel data. 
The processor accesses the controller while the 

20 controller is idle because an empty cell has been 
received. To ensure that sufficient empty cells are 
received, the switch core is run slightly faster 
(about 10%) than the rate needed to cope with the 
input and output ports with the result that the 

25 adapter card FIFOs 41 periodically drain below 
their one-cell thresholds, causing the empty cell 
insertion units 49 to operate. 

Although the processor has full access to ail 
the data structures in the controller, it does not 

30 have any access to the shared cell body memory. 

The general operation of the processor unit 24 
in effecting initialisation and connection set up is in 
accordance with known practices in the art and will 
not therefore be further described. The identity and 

35 nature of the actual controller data structures set 
up and modified by the processor unit 24 will 
become apparent from the description of the con- 
troller that follows. 

<tc QcrJtrs'Az? GsrteeeiS ami Overview 

Before describing in detail the data structures 
and processes used to implement the controller 33, 
the main concepts involved in its operation will first 
<s be previewed with reference to Figure 8. As will 
become apparent, the way in which multicasts are 
handled in the controller is central to its overall 
architecture. 

so Overall External Port Rota 

It is essential for the controller 33 to know from 
which external (adaptor card) port a cell header has 
been received because the (VPKVCI) information 
55 in each header is only unique on a per-link basis; 
the external port identity is thus necessary to 
uniquely identify a cell header as relevant to a 
particular instance of communication through the 
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switch. One way of informing the controller of the 
relevant externa) port identity would be to arrange 
for the adaptor cards to tag each cell header. 
However, it is possible to use a different approach 
for the present controller because both the order in 
which each adaptor card services its associated 
external ports and the order in which these adaptor 
cards are serviced through the corresponding 
switch core ports, are predetermined. Thus, in the 
present controller, the external port identity asso- 
ciated with a cell header is determined by the 
controller on the basis of when the header is re- 
ceived. More particularly, an external port rota is 
derived indicating the order in which cell header 
will be received from the external ports of all the 
adaptor cards connnected to the switch core; there- 
after, the controller 33 accesses this rota in co- 
ordination with the operation of the adaptor-card 
multiplexers 45, the controller 33 and multiplexers 
45 having been initially synchronised by the global 
synchronisation signal previously referred to. The 
external port rota itself is a combination of the 
switch-core port cycle shown in Figure 5 (showing 
in which order cell headers are passed from the 
switch-core ports to the controller), and the external 
port service cycle for each adaptor card (see Fig- 
ure 7). This combination is effected by taking the 
next entry on the external-port service cycle for an 
adaptor card, each time the corresponding switch- 
core port appears on the switch-core port cycle. 
Thus for a switch-core having the Figure 5 port 
cycle with switch-core port P1 connected to an 
adaptor card having a service cycle as shown in 
Figure 7, successive services of port P1 in the 
Figure 5 cycle will be associated with successive 
ones of the external ports A to E according to the 
Figure 7 cycle. 

The external port rota is, of course, dependent 
or, the port make-up of the adaptor cards con- 
nected to u"»c svvuCii ec<e. For ihis reason, rha 
external port rota is determined at start up of the 
switch by the processor unit 24 interrogating each 
adaptor card to discover its external-port service 
cycle. The processor unit 24 then stores the rota in 
an appropriate data structure 60A of the controller 
33 enabling the controller to access the rota as 
required. 

The external port rota is not only needed by 
the controller to determine the source of each new 
cell header it receives, but also to coordinate its 
output of headers with the predetermined order in 
which the external ports are made available for 
switch-core output (this being determined by the 
combined operation of the fabric 30 and the de- 
multiplexers 47 on the adaptor cards). As already 
noted, the order in which ports are serviced for 
input and output need not be the same but in 
genera! they will be. In the present case, the same 



general form of external port rota is used for output 
from the controller as for input the external input- 
port and output port rotas being respectively re- 
ferenced 60A and 60B in Figure 8. 

5 

Master and Output VCNs 

In order uniquely to identify a flow of asso- 
ciated cells in the switch, a VCN (virtual channel 

io number) is used by the controller. Every input 
virtual channel has its own VCN, called a "master 
VCN" and every output virtual channel has its own 
"output VCN". For each unicast connection through 
the switch, there is thus one master VCN and one 

75 output VCN, whilst for each multicast connection 
group, there is one master VCN and a plurality of 
output VCNs. For the unicast case, it is convenient 
to use the master VCN also as the output VCN; 
indeed even for the multicast case, it is convenient 

20 to use the master VCN also as the first one of the 
output VCNs. 

The master VCN is derived from the 
(VPI + VCI) of a cell header in combination with the 
identity of the external port providing the cell. Each 

25 cell header passed to the controller 33 will first 
have its master VCN determined (see block 61 in 
Figure 8) and this master VCN is then used to 
control queuing of the header in the controller. The 
output VCNs are allocated by the processor unit 

30 when setting up a connection and are used for 
effecting output queuing and scheduling. The out- 
put VCNs are associated with their corresponding 
master VCN in appropriate data structures of the 
controller enabling translation in both directions, 

35 that is, master VCN to corresponding output VCNs, 
and output VCNs to corresponding master VCN. 

Two Controller Paths 

40 As illustrated in Figure 8, there are two paths in 

the controller 33, one for queuing cell details (that 
is, for each cell, certain cell header data and the 
corresponding cell body address), and the other for 
queuing and scheduling output VCNs to control the 

45 output of cell headers from the controller 33. 

Cell Details Path - This path involves, after the 
lookup of the master VCN of a ceil header, a 
policing block 62 for checking whether the cell 
details for the cell concerned can be stored or 

so should be discarded, a cell-details queuing block 
63, and an output header generation block 64 that 
receives from block 63 cell details for the next 
header to be output, generates the new header 
(including looking up the new VPI + VCI), and out- 

55 puts the new header and the address of the cor- 
responding cell body. The cell details of cells with 
the same master VCN (i.e. cells from the same VC 
source) are all queued in the same LIST 65 stored 
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in the block 63, the cell details cf each cell being 
stored as a respective list entry. The list 65 is 
created, empty, by the processor unit upon set up 
of a connection. For each list, a cell-details input 
control 66 maintains a producer pointer 67 pointing 
to the tail of the list (which is where entries are 
added), and an empty flag indicating whether or 
not the list 65 is empty. 

The head of each list 65 is the cell-details 
entry for the oldest cell still to be sent out in 
respect of the incoming cell stream for the master 
VCN concerned. For unicast VCs, the head list 
entry identifies the next cell to be output for the 
sole output VC; this head entry is pointed to by a 
consumer pointer 68 maintained for the output 
VCN concerned by a cell-details output control 69. 
For multicasts, there are of course a plurality of 
output VCs for each input stream, and it is neces- 
sary to track for each output VC its progress along 
the corresponding list 65 in outputting cells; this is 
achieved by providing a respective consumer 
pointer 68 associated with each output VCN. In 
effect, a respective cell-details QUEUE 70 is kept 
for each output VCN, this queue being mapped 
onto the list 65 for the associated master VCN with 
the head of the queue being pointed to by the 
corresponding consumer pointer 68 and the tail of 
the queue being pointed to by the producer pointer 
for the master VCN concerned. This concept of 
having a respective cell-details list 65 associated 
with each master VCN, and respective queues 70 
mapped onto the list for the associated output 
VCNs, is an important one in the operation of the 
cell-details queueing block 63. y 

Upon the head entry of a queue 70 being 
output by the output control 69 to cause the output 
of a cell for the corresponding output VCN, the 
consumer pointer 68 for the queue 70 is adjusted 
to exclude that entry frcrr* the queue. When the 
M^aJ om.'jt o? a ;: si 65 cecr. zz:z:jCz£ from all 
the queuas 70 mapped onto the ;;si, tn;s entry is 
freed and the output centre! 63 also causes the 
corresponding eel! body address to be put back on 
the free address list 32. 

Output VCN Send ControS Path - The order of 
output of cells from the switch through the appro- 
priate external switch ports is determined by a 
send control path that operates on the basis of the 
output VCNs set up for the output virtual channels. 
As will be more fully described hereinafter, output 
VCNs are injected into this path by an output-VCN 
send kickoff block 82 that is itself "kicked" by the 
input-control 66 of the queuing block 63 whenever 
a list 65 changes from an empty to a non-empty 
state. Kicking the block 82 involves passing the 
block the master VCN of the list concerned; the 
kickoff block 82 converts this master VCN into the 
output VCNs associated with the master VCN - 



these output VCNs being those having associated 
queues 70 mapped onto the list 65 that has just 
become non-empty. These output VCNs thus re- 
present the Virtual Channels for which a cell has 

5 now become available for sending. The kickoff 
block 82 injects these output VCNs into the send 
control path (in particular, into an eligibility control 
block 77). Once an output VCN has been injected 
into the path, it will circulate in the path, periodi- 

io cally prompting the sending of a cell, until the 
corresponding cell-detail queue 70 indicates that 
there are no more cells available for sending in 
respect of the output VCN concerned. 

The main components of the send control path 

75 are the eligibility control block 77 and a scheduling 
block 75. The actual scheduling of eel! output is 
effected by the scheduling block 75 that maintains 
a respective queuing structure (see block 76) for 
each externa! port; each of these queuing struc- 

20 tures is used to queue the output VCNs of atl the 
output virtual channels that are associated with the 
corresponding external port and for which there is 
at least one cell eligible for sending. A virtual 
channel has one or more cells eligible for sending 

25 if there is at least one entry in the corresponding 
output VCN queue 70 (unless temporarily blocked 
from being sent - see explanation of "stop bit" 
below) and the virtual channel has credit for send- 
ing (as explained below) where such credit is re- 

30 quired. 

It is the job of the eligibility control block 77 to 
determine when an output virtual circuit has one or 
more eligible cells and when it so determines, it 
passes the corresponding output VCN onto the 

35 scheduling block 75 for queuing on the appropriate 
queuing structure. These queuing structures can 
thus be thought of as queuing "eligible" output 
VCNs. The queuing of the eligible output VCNs on 
the appropriate queuing structure is £Cm;svo3 by 
Storing in a rao?e 81 ?n Dlcck 77 the identity of the 
appropriate queuing structure for each output VCN, 
this informaiton being passed to block 75 with each 
ourput VCN. 

The operation of the eligibility control block 77 

<5 and associated blocks 80, 82 will be considered 
further later; for the moment, however, it will be 
assumed that the queuing structures of the sched- 
uling block 75 have been populated with eligible 
output VCNs. 

so The scheduling block 75 includes a scheduler 

78 whose operation is coordinated with the opera- 
tion of the fabric 30 and adaptor-card demultiplex- 
ers through synchronised access to the external 
port rota 60. The scheduler 78 examines the output 

55 VCN queuing structure for each external port in the 
appropriate slot of the rota 60. and outputs the 
VCN (if any) of highest priority for that structure on 
line 79 to the output control 69 of the cell details 
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queuing block 63. The output control 69 then uses 
the consumer pointer 68 for the VCN concerned to 
access the cell-details entry at the head of the 
corresponding celWetails queue 70 and passes 
these details to the output header generation block 

64 where the new header is generated; meanwhile, 
the output control 69 adjusts the consumer pointer 
68 for the VCN concerned to point to the next entry 
in the corresponding list 65. 

An output VCN will only appear once in the 
quauing structure 76 appropriate for the externa! 
port concerned, regardless of how many eligible 
cells there are for the corresponding VC. Each time 
the scheduler 78 outputs a VCN, it is removed from 
the corresponding queuing structure. The output 
control 69 on outputting cell details on an output 
VCN, passes this output VCN to the eligibility con- 
trol block 77 so that the latter can decrement the 
credit for that output VCN; at the same time, if the 
output control 69 determines that there are one or 
more further cells ready for sending on the cor- 
responding cell-details queue 70, then it will so 
inform the eligibility control block 77 by passing it 
a "more-cells" indication. If the eligibility control 
block 77, after updating, has further send credit 
recorded for this output VCN (or if no credit is 
required), then the output VCN is passed back to 
the scheduling block 75 where it rejoins the cor- 
responding queuing structure; however, if no send 
credit is immediately available (and is required), 
then the eligibility control block 77 awaits the re- 
ceipt of such credit from a credit provision block 80 
before passing on the output VCN to the schedul- 
ing block 75. The credit status of each output VCN 
is held in the table 81 kept by the eligibility control 
block 77. 

If the output control 69, after outputting cell 
details for a particular output VCN, determines that 
the corresponding queue 70 is empty, it dees not 
f?*ss ihc rr.crc cc;;3" .r.ciic^-o- heck to trtc c::> 
gibvliy centre: bice:: V7. However, tf at iho same 
time, the output control 69 determines that there 
are no entries remaining in the corresponding list 

65 (all queues 70 relevant to the list having been 
emptied), it signals this to the Input control 68 to 
cause the empty flag for the list to be set. 

From the foregoing, it can be seen that once 
the eligibility control block 77 has been signalled 
by the kickoff block 82 that a new cell has arrived 
on the queues 70 of particular output VCNs, each 
of these output VCNs gets circulated around be- 
tween block 77, the scheduling block 75 and the 
output control 69 until the latter determines there 
are no more eligible cells for that output VCN (it 
being appreciated that new entries may be added 
to the relevant queues 70 whilst the output VCNs 
are awaiting scheduling in respect of each entries). 
The non-availability of send credit may temporarily 



halt this process but as soon as new credit be- 
comes available, the process recommences. 

When an output VCN ceases to be circulated 
(because there are no more entries available in its 
s queue 70), then it must await re-injection into the 
send control path by the kickoff block 82 before it 
can be rescheduled for sending. 

Quality of Service 

70 

The switch offers connections with three dif- 
ferent qualities of service, these are: 

- Guaranteed Bandwith with low maximum la- 
tency (GB0) 

75 - Guaranteed Bandwith with higher maximum 
latency (GB1) 

- Best Effort (BE) 

To this end, each external port queuing structure 
(block 76) in the scheduling block 75 actually com- 

20 prises three queues, one for each quality of ser- 
vice, and each eligible output VCN is added to the 
appropriate queue (the identity of this queue being 
held in table 81 of the eligibility control block and 
being passed to block 75 with the output VCNs). 

25 As will be appreciated, this results in a fair queuing 
policy within each class of service. Figure 9 illus- 
trates the external-port output VCN queues main- 
tained by the scheduling block and shows the 
provision of three queues per external port in the 

30 case of an external port identified as Port 0. Each 
time the scheduler 78 examines an external-port 
queuing structure in the corresponding slot of the 
rota 60, it will take the output VCN at the head of 
the highest priority non-empty queue, the priority 

35 order of the queues being GB0, GB1, BE. 

For the Guaranteed Bandwith Services, an ap- 
propriate amount of the shared memory 31 is re- 
served for each input VC subject to such service, 
furthermore, as will be described hereinafter ?o 7 

40 me Guaranteed BenawfGth services, a credit con- 
trol scheme is operated based on token buckets. 
Should a Guaranteed Bandwith Source exceed its 
guarantee (that is, it produces more cells per unit 
time than the switch has guaranteed to handle), 

45 then the eligibility control block will either tem- 
porarily haft the sending cells for that VCN (shaped 
output) or will temporarily treat the connection as a 
Best Effort connection (unshaped output). 

Best Effort traffic may or may not be flow 

so controlled. In the case of flow controlled traffic, a 
fixed amount of memory will be allocated to each 
input VC and credit will be issued to upstream 
nodes based on the amount of this memory that is 
free. For each output VCN a count will also be 

55 maintained of the credit that downstream nodes 
have advertised. This upstream/downstream credit 
control is managed by a flow control block 85, the 
credit count for a flow-controlled output VCN being 



21 



EP 0 680 179 A1 



22 



kept in the present node by the eligibility control 
block 77. When this credit count becomes zero, the 
eligibility control block prevents the VCN being 
passed to the corresponding scheduler queue, 
thereby halting transmission. 

Best Effort connections which are not flow con- 
trolled can have an arbitrary amount of memory 
allocated to them. If there is contention on the 
output and this memory is exhausted then cells will 
be dropped. 

Multicasts, Empty Flags and Stop Bits 

As described above, in the case of a multicast 
(multiple output VCs for one input VC), the cor- 
responding cell-details list 65 has several queues 
70 mapped onto it, each corresponding to a par- 
ticular output VCN. Again, as already described, 
the output control 69 for the queuing block 63 does 
not cause the empty flag of a list 65 to be set until 
all the queues 70 associated with the list 65 are 
empty. The reason for this is that the change of the 
empty flag from its set to unset state upon arrival 
of a new header whose cell details are to be 
queued on the list 65, causes the input control 66 
to "kick" the send kickoff block 82 resulting in 
injection into the send control path of all the output 
VCNs associated with the list; if the empty flag of a 
list were to be set upon only one associated queue 
70 becoming empty, then the send kickoff block 82 
could be kicked to inject output VCNs into the send 
control path when some of the output VCNs were 
still present in the path. The result of this would be 
unfair output scheduling. 

During switch operation, it may happen that a 
new list entry is added between the time: 

(i) one of the queues becomes empty following 
consumer pointer adjustment to exclude from 
the queue 70 the head entry cf the list 65 after 
umo e^'M ;>as beer* 'jsee for cjtputt:r.g a cg" 
;-,3aucf *Gf i*ie ouipui VC ccncernsa. ana 

(ii) another of the queues has the same list entry 
excluded by consumer pointer adjustment, again 
after the entry has been used for outputting a 
header for the output VC related to that queue. 

In these circumstances, the second of the aforesaid 
queues will not be empty when it excludes the 
entry that made the first of the queues empty and 
so the empty flag will not be set by the output 
control 69, even if all other queues are empty. It 
will be apparent that queues that have become 
empty under these cirucmstances may not get a 
chance to re-enter the scheduling process because 
new cell details entries could continue to be added 
to the list in a way that the aforesaid non-empty list 
always remains such. Because there will be a finite 
limit to the amount of memory allotted to a particu- 
lar input VC, in due course, cells will be lost. 



In order to avoid this problem, each cell-details 
entry In a list 65 has an associated "stop-bit". If in 
a multicast case, a queue 70 becomes empty, the 
output control 69 will set the stop bit of the head 

5 entry (i.e. the entry just excluded from the empty 
queue). Upon any other queue on the same list 
excluding this entry (because a cell header based 
on it has been sent out for the output VCN con- 
cerned), the corresponding output VCN is not re- 

10 circulated back to the eligibility control block 77; 
the queue has been effectively "stopped". How- 
ever, once all queues have used the entry whose 
stop bit is set, that entry is removed and the VCN 
send kickoff block is kicked by the output control 

75 69 (see "un-stopped" kick in Figure 8) with the 
corresponding master VCN to re-inject all the rel- 
evant output VCNs into the send control path. 

The Output VCN Send Kickoff Block 

20 

The general functionality of the kickoff block 82 
has already been described but several addition 
points are worthy of comment at this stage. The 
block 82 comprises a multicast expander 83 and 

25 an output circuit 84. The multicast expander 83 is 
arranged to make available all the output VCNs 
corresponding to a particular master VCN when the 
expander 83 is "kicked" with that master VCN. The 
multicast expander 83 is (re)programmed with ap- 

30 propriate data from the processor unit each time a 
connection is set up or taken down so that it is 
continuously kept up to date and able to relate 
every current master VCN with the corresponding 
output VCNs. The output VCNs made available by 

35 the expander 83 are passed one by one by the 
output circuit 84 to the eligibility control block 77. 

The Kickoff block 82 is implemented in a way 
enabling it to absorb all the kicks it receives whilst 
not having to complete the processing associated 

40 wi'ih each kick before it can receive another. This 
can be done, for example, by including an input 
FIFO for the kicks or possibly by providing an 
output VCN FIFO; generally, what is needed is the 
provisions of FIFO buffering at a point upstream of 

45 where the biock 82 needs to effect per output VCN 
operations, such as transfer to the eligibility control 
block 81. 

The importance of this arrangement and of the 
circumstances under which the block 83 is kicked 

so is that the expansion inherent in multicasting is 
dealt with in a way that produces the minimum 
processing strain on the controller. Thus, each 
master VCN and output VCN only ever has one 
occurence in block 83 and this permits particularly 

55 efficient memory utilisation to be effected. Further- 
more, the per output VCN processing associated 
with any particular kick does not have to be fin- 
ished before the next kick can be received. 
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Controller Implementation Details 

A more detailed description will now be given 
of the main components of the controller. 

Master VCN Lookup Block 

As already described, when a cell arrives at the 
switch core, its header is passed to the controller 
33; here, it is initially handled by the master VCN 
lockup block 61. On receipt at the block 61, the 
header consists of the following fields: 

- Generic Flow Control (GFC), 4 bits, 

- Virtual Path Identifier (VPI), 8 bits, 

- Virtual Channel Identifier (VCI), 16 bits 

- Payload Type (PT), 3 bits, and, 

- a bit which for AAL5 connections forms an 
End of Packet bit (EOP). 

Note that by this time the fifth byte of the header, 
the Header Error Check (HEC) has been removed 
because it has been verified in the appropriate 
adapter card. A failed HEC will have resulted in the 
cell being marked as empty (VPI = VCI = 0). 

The cell body address is also passed to the 
VCN lookup block 61 along with the corresponding 
cell header. 

The following operations are performed on the 
header by block 61 : 

- the cell is discarded if its VPI and VCI are set 
to zero, this discarding being done by return- 
ing the cell body address to the free address 
list 32; 

- the GFC is discarded; 

- the PT and EOP are extracted for storage 
with the cell body address so that the output 
header can be generated correctly, these 
items being referred to herein as the "cell 
details"; 

port on which the cell was received to pro- 
duce a unique identifier (herein the long 
channel identifier) for the connection which 
the cell is associated; the long channel iden- 
tifier is then used to look up the master VCN 
associated with the cell. 
It is this fourth function which is the main one 

for the block 61 and will now be described in more 

detail. 

The VPI and VCI information used to derive the 
long channel identifier for a cell are directly avail- 
able from the cell header; the port number identify- 
ing the external input port on which the cell has 
been received is derived in the present embodi- 
ment from the external input-port rota 60A, each 
external port appearing in the rota having an asso- 
ciated unique number. 



Once the input port number has been obtained 
it is concatenated with the VPI and VCI to give the 
long channel identifier which is about 30 bits long 
(the exact length will depend on the number of 
s ports the switch can have). This number is then 
used to find the master VCN of the connections 
with which the cell is associated. 

As it is impractical to have a simple lookup of a 
number this size, a multistage lookup process is 
io used. 

The lookup process comprises the following 
steps: 

1. The long channel identifier (VPI + VCI + 
port number) is scrambled in scrambler 90 (see 

ts Figure 10). The scrambler may be of standard 
form such as one based on a linear feedback 
shift register where the channel identifier is used 
as a seed word for the linear feedback shift 
register which is then shifted by the word length 

20 to give the scrambled output word. 

2. The scrambled long channel identifier is di- 
vided into two parts by splitter unit 91 . One part 
(the top part) is used to look up a "row index" in 
a "high table" 92 and the other part (the bottom 

25 half) is used to "look up" a "column index" in a 
"low table" 93. 

3. The "row index" and "column index" are then 
used to access a two-dimensional table 94 
which contains the master VCNs. 

30 4. Finally, the master VCN is used to look up a 
long channel identifier in a check table 95, this 
identifier corresponding to the one that should 
have been used in step 1 if all is working well; 
the looked up identifier is compared against the 

35 actual original long channel identifier in com- 
parator 95 to check that the process of steps 1 
to 3 did not give a false result (if it did, the cell 
is discarded by adding the cell body address to 

tMO IfOO CiViC'fOOO 
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of the lookup process are as follows: 

Step 1 . The need to scramble the long chan- 
nel identifier arises because it is like- 
ly that most long channel identifiers 

45 for cells from the same link will have 

identical top halves (probably zero). 
Unless the long channel identifiers 
are scrambled, they would therefore 
all index to the same index in the 

so high table 92 allowing only one row 

of the master VCN table 94 to be 
used. Scrambling distributes differ- 
ences across the whole identifier, 
thus improving the utilisation of both 

55 the row and column tables, allowing 

the master VCN table to be used 
more efficiently. 
Step 2. The scrambled long channel iden- 
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tifier is split in half because tt is 
impractical to look up a 30-bit num- 
ber, while it is quite practical to look 
up a 15-bit number (a 32K entry 
table is needed). Splitting the num- 
ber into more pieces would result in 
three 1K tables. While this appears 
at first to be attractive, the resulting 
tables are too small to allow many 
VCs to be supported so this option 
would only be suitable in special sit- 
uations. 

Step 3. The result of the high and low table 
lookups are used to index the master 
VCN table because, although these 
two results uniquely identify the con- 
nection, the results are sparse. This 
is because the process does not 
work well when the master VCN ta- 
ble is more than about a quarter full. 
Therefore using the high and tow 
tables results directly would give a 
VCN space four times bigger than it 
needs to be and would push up the 
memory requirements of all the per 
VCN data structures in the rest of 
the controller accordingly. 
Step 4. The long channel identifier check is 
done because it is possible that celts 
might arrive on VCs that have not 
been set up. If the check was not 
performed and such a VC happened 
to index a valid master VCN, then its 
cells would be treated as if they had 
come in on the VC corresponding to 
that master VCN. 
The foregoing lookup process allows fast 
lookups of large numbers of VCNs to be performed 
at tow cost in hardware. For instance 8000 master 

require a 32KxS hlgn table, s 32KxS tow iabie, a 
64Kx13 master VCN table and a 8Kx30 choc »t 
table. 

When a VC connection is set up, the processor 
unit 24 calculates the entries to put in the various 
tables of the master VCN lookup block 61 . In doing 
this, it is possible that the processor unit might find 
that a particular VC will not fit into the existing 
tables without conflict with a previously set up VC 
(in particular, the scrambled long channel identifi- 
ers of the new and previous VC both map into the 
same master VCN table entry). In this case, the 
processor unit 24 is arranged to change the scram- 
bling function used by the scrambler 90 and to 
rearrange the tables so that a conflict no longer 
exits. In order to support this operation, the high, 
low and master VCN tables are double buffered, 
allowing lookup to continue in the active table while 



the processor unit rewrites the inactive table. 
Policing Block 

5 The role of the policing block 62 is to decide 

when ceils should be dropped. The need arises to 
drop cells if they are arriving on a VC faster than 
they are being sent. This will only occur in two 
circumstances, namely: 

io - best effort connections are contending for an 
output; 

- a guaranteed bandwith connection has ex- 
ceeded its guarantee. 

The mechanism used to decide whether to drop 

75 cells is described below. 

As already mentioned (see "Quality of Service" 
section), when a new VC is set up through the 
switch, a fixed amount of memory from the shared 
memory 31 is allocated to the input side of the VC 

20 in dependence on the quality of service to be 
provided. The amount of memory allocated is 
known as the "allocated memory utilisation" or 
"allocated MU" for the input VC concerned. The 
policing block 62 keeps a record of the allocated 

25 MU of each input VC by reference to the cor- 
responding master VCN. 

The shared memory 31 can be considered as 
divided into two areas: the reserved area, whose 
size is equal to the sum of all the allocations, and 

30 the unreserved area, which makes up the rest. An 
input VC may be allowed to exceed its allocated 
MU and store cells in the unreserved memory area 
under certain conditions. It should be noted that the 
memory is not actually split into separate areas, it 

35 just behaves as if it were. 

The policing block 62 maintains a record of the 
amount of memory from the shared memory 31 
that is currently being used in relation to each 
master VCN: this memory arr.cunt ;s k^ovvn ?s t^e 

cz cuhefti memory utilisation, cr current iViU. for each 
master VCN. The current MU of a master VCN is 
incremented by block 67 when it receives a cell 
header for the master VCN concerned, and is de- 
cremented when the output control 69 of the queu- 
es ing block 63 indicates that a cell has been sent on 
all relevant output VCNs and the corresponding 
area of the cell body memory can be freed (by the 
cell body address being placed on the free address 
list 32). 

50 When a header with a particular master VCN 

arrives at block 62, indicating the arrival of a new 
cell body in the memory 31 for a corresponding 
VC, the policing block 62 must decide whether or 
not to drop tho cell. It does this using the following 

55 criteria: 

- if the master VCN's current MU is less than 
is allocated MU, the cell is not dropped and 
the current MU is incremented; 
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- if tho VCN's current MU is greater than or 
equal to the allocated MU, the cell will be 
dropped unless the amount of space used in 
the unreserved memory region is less than 
some predetermined threshold. If the cell is 
not dropped its current MU is incremented as 
is the record of used space in the unreserved 
memory region. 
In order to maintain the record of current used 
space in the unreserved memory area, the policing 
block 62 must also examine the allocated MU of a 
master VCN when a cell has been sent out on all 
associated output VCNs and the corresponding 
shared memory address has been freed. If the 
current MU of the master VCN is, before de- 
crementing, greater than the corresponding allo- 
cated MU, the record for the current used space in 
the unreserved area must also be decremented to 
take account of the freed memory space. 

It should be noted that the monitoring of cur- 
rent MU is the only mechanism in the switch which 
can drop cells. This means that once cells have 
passed this check they can never be dropped. 

It should also be noted in relation to guar- 
anteed bandwith services that the switch does not 
directly monitor the traffic at its input in order to 
establish whether a VC is exceeding its guarantee 
and so determine whether cells have to be 
dropped. Instead it relies on the indirect 
mechanims of monitoring current MU to establish 
when a VC is trying to exceed its bandwith guar- 
antee. 

For AAL5 connections the controller can see 
the End of Packet (EOP) bit in the cell header. 
Thus, provided the controller is informed at con- 
nection set up whether a particular connection is an 
AAL5 connection, the controller can decide, after 
dropping a cell on an AAL5 connection, to drop all 



i8 not diupued 
here, tnsse ce;;s will cause unnecessary traffic and 
related processing as they will in any case be 
dropped at the destination by the protocol layer 
responsible for ensuring that only complete pack- 
ets survive. 

The policing block 62 can be arranged to im- 
plement the dropping of the remainder of a packet 
following the dropping of one cell on an AAL5 
connection. 

It should be noted that a cell with the EOP bit 
set must be sent out before the next AAL5 packet 
is sent, otherwise it too will be ruined. There are 
two possible methods of doing this (see Figure 11): 
1. drop all the ceils in the rest of the packet 
except the one 102 with the EOP bit set (that is, 
drop cells shown in dashed box 101 in Figure 

11); 



2. drop the rest of packet (including the cell 102 
with the EOP bit set), but set the EOP bit 103 
on the last cell 104 before the dropping started; 
thus the ceils shown in dashed box 105 are 
5 dropped. 

Method 1 requires, if the next packet is never 
to be affected, an extra buffer for every AAL5 VCN, 
so that space for the last ceil can be guaranteed. 
Method 2 does not require this extra buffer but 
10 does require that a mechanism is included in the 
Ceil Queuing block 63 to change the EOP bit of an 
already stored ceil, making the implementation 
more complex. Accordingly, method 1 is preferred. 
The requirement of method 1 of having to 
15 reserve an extra buffer for each AAL5 connection 
can be dealt with by using the unreserved area of 
memory 31 for storing the ceil with the EOP bit set, 
if the area reserved for the connection concerned 
is full when this cell arrives. This approach will only 
20 cause problems if both the unreserved area and 
the area reserved for the connection are full. In this 
case the switch must continue dropping cells on 
the connection so discarding the next packet. 

Dropping cells according to method 1 requires 
25 that two extra flags be maintained for each VCN 
connection, these flags being stored in association 
with the master VCN of the connection. The first 
flag is an AAL5 flag and is set when an AAL5 
connection is established. The second flag is a 
30 dropping flag and indicates that cells on this mas- 
ter VCN should be dropped up to the cell marked 
with the EOP bit set. 

This criteria for dropping cells then depends on 
the state of the dropping flag. If the dropping flag is 
35 not set then the criteria and actions are as before 
except that if the cell is dropped and the AAL5 flag 
is set then the dropping flag is set. 

If the dropping flag is set then the criteria are 
as follows: 

40 if the cei! Goes not have iho EOP bit est then 

it is dropped, 
. if the cell has the EOP bit set then; 

- if the master VCN's current MU is less 
than its allocated MU the cell is not 

45 dropped, the current MU is incremented 

and the dropping flag is reset, 

- if the master VCN's current MU is greated 
than or equal to the allocated MU the cell 
will be dropped unless the amount of 

so space used in the unreserved region 

[something missing - between brackets ?] 
is less than some threshold. If the cell is 
not dropped its current MU is incremented 
as is the count of used space in the unre- 

55 served region. If the cell is not dropped 

then the dropping flag is reset. 
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Cell Details Queuing Block 

Once a cell has passed the checks imposed by 
the policing block 62, the ceil details (including the 
cell body address in memory 31) are queued as an 
entry on the appropriate master VCN list 65. Each 
list 65 is a singly listed list and each entry com- 
prises, as well as the cell body address and header 
information on the corresponding cell, several fields 
used for maintaining the list. More particularly and 
with reference with Figure 12, each list entry 110 
comprises the following fields: 

- a field 1 12 for the cell-body address; 

- a field 113 for the Cell Type and EOP bit 
needed to reconstruct the cell's header; 

- a field 114 for storing a reference count that 
is used for multicasts to indicate the number 
of times the cell still needs to be sent before 
it can be discarded (that is, before the mem- 
ory used to store the cell body and current 
cell-details entry can be freed); 

- a field 115 for storing the stop bit for the 
entry, this bit being used for multicasts as 
explained above; and, 

- a field 116 for holding a Next entry pointer 
117, pointing to the next entry in the linked 
list. 

The next entry pointer 117 points away from 
the head of the list 65 (the head entry being the 
oldest in the list) to the next entry in the direction 
of the tail of the list where new cell details are 
added. The tail entry is always a null entry 111, 
that is, all its fields are set to null; the adding of 
new cell details involves filling the null fields of the 
current tail entry with the new cell details and 
adding a new null entry. 

A data structure 120 of the input control 66 
maintains for each master VCN (and, thus, for each 

». • wv -- -*-■ 

3 ^B'd 1 21 to;- tj»9 prcciucsr pointer 6/ point- 
ing to the tail entry of the corresponding list 
65; 

- a field 122 holding the empty flag for the list, 
this flag being set when all queues 70 on the 
list are empty; and, 

- a field 123 holding an initial reference count 
indicating the number of output VCNs asso- 
ciated with the master VCN. 

The data structure 120 is accessed using the 
master VCN of interest. 

A data structure 125 of the output control 69 
maintains, for each output VCN, the following 
fields: 

- a field 126 for the consumer pointer of the 
queue 70 associated with the output VCN 
concerned; and, 

- a field 127 containing the identify of the mas- 
ter VCN associated with the output VCN (this 



enables the information cn the master VCN 
that is held in data structure 120 to be acces- 
sed where only the output VCN is initially 
known). 

5 The data structure 125 is accessed using the 

output VCN of interest. 

The use of the above-described data structures 
is best understood by considering what happens 
when a cell arrives, and then considering what 

w happens when a cell is sent. 

Queuing a cell - When a eel) arrives, the master 
VCN, Cell Type, EOP bit, and the cell body ad- 
dress for that cell are passed to the input control 
66 of the queuing block 63 and the following oper- 

75 ations are then effected. 

1 . First the master VCN is used to look up the 
corresponding producer pointer, Empty flag and 
Initial reference count in data structure 120. 

2. The producer pointer is then used to access 
20 the null tail entry of the appropriate list 65 and 

the cell body address, Cell Type, EOP bit and 
Initial reference count are written into the cor- 
esponding fields of the entry and the Stop bit is 
set to zero. 

25 3. Once this has been done the address of a 
new list entry is obtained from a free list entry 
FIFO (not shown) and written into the Next entry 
field. 

4. Finally, the relevant pointer is advanced by 
30 setting it to the value obtained from the free 
entry list. 

An example of queuing a cell-details entry is 
shown in Figure 13 for a multicast case where 
there are three ouput VCNs associated with the 

35 master VCN concerned (i.e., the initial reference 
count equals 3). Figure 13A shows the relevant list 
65 before adding of the new entry commences, 
Figure 13B shows the list after the new cell details 
have be zr. inserted into the ferrr.erlv t^i! er.trv 

i'j and Figure 13C shews the list after c new r.ul! tail 
entry has been added to complete the entry-addi- 
tion process. 

The important point to note from the foregoing 
example is that the queuing of a celi-detaiis entry 

45 in the multicast case has been effected in the 
same number of operations as it would have taken 
for the unicast case. This is possible because a 
null entry is always kept at the tail of each list. 
Thus an empty list consists of a single null entry 

so with the corresponding producer pointer and the or 
each consumer pointer pointing at it. 

After queuing a cell-details entry to a list 65 
that has its empty flag set the input control 66 
must kick the multicast expander 83 to inform it 

55 that a cell has arrived on the master VCN con- 
cerned. As well as containing the current master 
VCN, the kick also includes a flag to tell the mul- 
ticast expander 83 whether the master VCN is 
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multicast. This flag is set when the initial reference 
count is not equal to one. By providing this flag a 
lookup is saved in the multicast expander (this is 
because in the present implementation, the first 
output VCN is always the same as the master VCN 5 
with which it is associated). 

Once the kick has been sent, the input control 
66 clears the empty flag for the list concerned. 
Note that this is the only time that the empty flag is 
cleared. io 
Sending a cell - Once the scheduling block 75 
has decided that a cell should be sent on a particu- 
lar output VCN, it tells the output control 69 of the 
queuing block 63. After receiving the output VCN, 
the output control 69 must retrieve the cell details 75 
information for the head entry in the queue 70 for 
the output VCN; this is readily done as the output 
control 69 simply uses the output VCN to obtain 
the consumer pointer 68 for the relevant queue and 
hence can immediately access the required cell 20 
details (the ceil body address, cell type and EOP 
bit). This information is then passed on the output 
header generation block 64 for sending. 

Once the cell details have been sent there are 
a number of housekeeping operations which must 25 
be performed to maintain the relevant queue 70 
and linked list 65 and to inform other blocks of 
changes to the queue and list. 

Figure 14 is a flow chart representation of the 
process of outputting cell details and the resultant 30 
housekeeping required, the already described op- 
eration of outputting the cell details being shown as 
block 130. The use of a flow chart should not be 
taken as implying that the operations concerned 
are performed in software; in fact, for reasons of 35 
speed of execution, a hardware implementation will 
generally be required. 

The housekeeping operations required follow- 
ing Ihe outputting of cell details are: 

(i) io work out if ihe reinvent queue 70 is empty to 
(biock 131); 

(ii) to work out if the cell details entry just output 
should be freed (block 132); 

(iii) if the entry is to be retained, to carry out 
entry reiated housekeeping (entry housekeeping 45 
block 133); 

(iv) if the entry is to be freed, to free the entry 
and carry out list related housekeeping (list 
housekeeping block 134); 

(v) to move the consumer pointer (queue house- 50 
keeping block 135); and, 

(vi) to work out whether the output VCN should 
continue to be considered for scheduling (block 
136). 

These operations are described below. 55 
(i) Queue empty (block 131) ? - To work out if 
the relevant queue 70 is empty, the Next pointer 
of the queue entry just output is compared to 



the producer pointer for the list 65 onto which 
the queue is mapped. If the Next pointer and 
producer pointer match, then there are no more 
entries in the queue waiting to be output - cn 
other words, the queue is empty. In order to 
look up the relevant producer pointer, the output 
control 69 must first identify the master VCN 
corresponding to the current output VCN, and 
this is done by referring to field 127 of data 
structure 125 (see Figure 12). The output control 
then uses the master VCN to access the data 
structure 120 and retrieve the required producer 
pointer. For the unicast case, if the sole output 
VCN has been made the same as the master 
VCN, then of course the data structure 120 can 
be accessed directly using the output VCN to 
look up the producer pointer. If after comparing 
the next pointer and producer pointer, the queue 
70 is found to be empty, a temporary flag CQE 
(Current Queue Empty) is set by the output 
control 69, this flag being internal to the output 
control. 

(ii) Can entry be freed (block 132) ? - An entry 
can only be freed from the list 65 on which it is 
queued when it has been output for all the 
output VCNs having queues 70 mapped onto 
the list 65. The reference count field 114 is used 
to keep track of how many more times an entry 
must be output (as already described, the refer- 
ence count is initially set by the input control 66 
to a value corresponding to the total number of 
queues mapped onto the list). To decide wheth- 
er an entry can be freed, the output control 69 
has only to check the reference count field 114- 
if it has a value of one, the entry can be freed 
(the value of one being for the outputting of the 
entry that has just occurred in block 130). 

(iii) Entry Housekeeping (block 133) - If an entry 
Is net yet to be freec! tts reference cour* ^e!c? 
in field 114 is decremented to track tha niimbe*' 
of output VCs for which the entry has yet to be 
output. Furthermore, if the current queue is now 
empty (as indicated by the CQE flag, potentially 
set in biock 131), then the stop flag of the entry 
is set, ensuring all queues 70 in a multicast case 
are brought back into step as previously ex- 
plained. An example of use of the stop bit is 
given hereinafter. 

(iv) List Housekeeping (Block 134) - If a list 
entry is to be freed, then this is done by placing 
the entry address on the free address list main- 
tained for list entries. In addition, the cell body 
address is placed on the free address list 32 
(Figure 4). Next, the output control 69 tests the 
CQE flag and if this flag is set (indicating that 
the current queue is empty), the output control 
knows that the corresponding list is also empty; 
in this case, the output control causes the cor- 
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respondig empty flag 122 in data structure 120 
to be set. If the CQE flag is not set, indicating 
that there are more entries to send, but the stop 
bit of the entry just output was set, then the 
output control 69 knows that all queues of a 
multicast case have now been brought into step 
so that the corresponding output VCNs can be 
re-injected into the send control path; to do this, 
the output control 69 sends an n un-stopped n 
kick to the VCN send kickoff block 82. Finally, 
the output control messages the policing block 
62 to inform it of the new list length after re- 
moval of the entry just output. 

(v) Queue Housekeeping (block 135) - The only 
housekeeping required for the current queue 
(the queue from which cell details information 
was output in block 130) is the updating of the 
consumer pointer 68 to point to the next entry in 
the queue; to do this, the output control 69 
simply sets the consumer pointer to the Next 
pointer value held in the entry just output. 

(vi) Should the Output VCN be Recycled (block 
136) ? - The output control 69 passes the eli- 
gibility control block 77 the current output VCN 
to enable the latter to decrement the corre- 
sponding credit count. At the same time, the 
output control 69 considers whether the output 
VCN upon which it has just acted can be re- 
cycled back to the send control path. The output 
VCN is only recycled if there are more entries in 
the corresponding queue 70 (that is, the CQE 
flag is not set) and, for multicasts, the entry just 
sent does not have its stop bit set to indicate 
that multicast queues are being aligned at the 
entry. The output control 69 tests for this com- 
bination of circumstances and, if present, sends 
a "more cells" indication to the eligibility control 
block along with the output VCN. 

Ma^mn w<\c^^|>'v^ q^^^"^' ^u^ct cnirt n cf tt"ie 
nsts 65 ep.c? queues 70 £S wo!! cis the detailed 
steps taken by the input and output controls 66, 69 
to implement this functioning, an example will now 
be given to assist a full understanding, particularly 
as regards the functioning of the stop bit in regulat- 
ing the output of entries from multicalt queues 
mapped onto the same list 65. 

Figure 15A illustrates a list 65 having five en- 
tries made up of entries for cells CelM , Cell2, Cell3, 
Cell4 and a null entry at the tail of the list; for 
clarity, only the stop bit field and Next entry pointer 
field have been individually shown for each entry, 
the other fields being represented by the label 
CelM, Cell2, Cell3, Cefl4 and Null as appropriate. 
Three queues 70 are mapped into the list by 
means of respective consumer pointers C1, C2 and 
C3 that point to the head of each queue, the tail of 
each queue being the null entry. Thus, the queue 
(the first queue) associated with pointer C1 that 



points to entry Ce!l1, has four entries waiting to be 
sent (Cell! to CelI4); the queue (the seond queue) 
associated with pointer C2 that points to the Null 
entry has nos entries waiting to be sent; and the 

5 queue (the third queue) associated with pointer C3 
that points to entry Cell2, has three entries waiting 
to be sent (Cell2, Ce!i3, Cell4). 

At the time that the second queue became 
empty, the output control 69, in carrying out the 

to entry housekeeping of block 133 of Figure 14, set 
the stop bit of the entry just output (the entry 
Cell4), this being indicated by "STOP = 1 " in Figure 
15A. The output VCN associated with the second 
queue was not recycled by the output control. 

75 Figure 15B shows the addition of a new entry 

CellS to the list of Figure 15A, the entry details 
being entered into the previous Null entry at the tail 
of the list and a new Null entry being appended to 
the list. The consumer pointers C1 , C2, C3 point at 

20 the same entries as before. 

Even though there is now a new entry in the 
second queue, it will not be sent as the cor- 
responding output VCN is not currently in the send 
control path and is therefore not available for 

25 scheduling. However, the output VCNs for the first 
and third queues are still in the send control path 
and are being scheduled; each of these queues will 
therefore be progressively reduced in length. As a 
list entry is output for the third time (this may be in 

30 respect of the first or third queue) the entry is 
freed. In due course, the entry Cell4 will be output 
from one of the first and third queues and at this 
time the output VCN associated with the queue is 
not recycled because the stop bit of the Cell4 entry 

35 is set; the corresponding consumer pointer thus 
comes to rest on the entry Cell5 along with pointer 
C2. Eventually, the Ce»4 entry is output by the last 
of the three queues and the corresponding con- 
si '?«T»o" OOf-Tvc 7 SE* tO "OS: 7 *? tO B^t 7 ^ Os"5. V^.S SrTi^y 

4G Cc"4 ;s freed and me Output control 69 feeoc^ilses 
that it needs to kick the kickoff block 82 to reinject 
the output VCNs of all three queues into the send 
control path to restart the outputting of entries from 
these queues. 

45 

Send Kickoff Block 

The output VCN send Kickoff block 82 takes a 
"kick" on a particular master VCN and expands it 

so into all the associated output VCNs. In the present 
embodiment, the first output VCN is made the 
same value as the master VCN so that for the 
unicast case, the master VCN can be directly taken 
as the output VCN. The output VCNs provided by 

55 the expansion operation are passed on from the 
block 82 to the eligibility control bock 77 when the 
latter asks for them. 
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As already described, Kicks may originate from 
the input control 66 upon a list 65 passing from an 
empty to a non-empty state ("non-empty" Kicks) or 
from the output control 69 upon all queues 70 on a 
list aligning at an entry following one whose stop 
bit was set ("un-stopped" Kick). Kicks from the 
latter source will always be associated with mul- 
ticast cases whereas Kicks from the input control 
66 may relate to unicasts or multicasts. The input 
control 66 will know from the data stored in field 
123 of data structure 120 (see Figure 12) whether a 
master VCN relates to a unicast or multicast and 
passes this information along with the master VCN 
when effecting a "non-empty" Kick on the send 
Kickoff block 82. 

Thus, the block 82, on receiving a Kick, will 
know both the master VCN concerned and whether 
it relates to a unicast or multicast connection. 

As noted above, the send Kickoff block in- 
cludes buffering placed upstream of any per output 
VCN operation. One way of doing this it to imple- 
ment the multicast expander 83 as a Kick FIFO 140 
(see Figure 16) for storing each Kick received, and 
a multicast group store 141 storing for each mul- 
ticast connection the group of related output VCNs. 
The general operation of block 82 is then as fol- 
lows. When a Kick is entered in the Kick FIFO 140 
to record the master VCN concerned, an asso- 
ciated multicast flag is appropriately set to indicate 
whether or not the Kick relates to a multicast con- 
nection. The stored Kicks are then processed in 
FIFO order by the block 82, output circuit 84 out- 
putting when requested by the eligibility control 
block 77, the or each output VCN associated with 
the master VCN of a Kick. In particular, if a Kick 
relates to a unicast master VCN, then the output 
circuit 84 simply outputs the master VCN as the 
corresponding output VCN; however, if the mul- 
ticast flag of a Kick is set to indicate that it relates 
\o a mi^icae* raster VCW, t!~.sri t^s Cuipui clicuii: 
S4 uses the master VCfo to index into the multicast 
group store 41 and output In turn each associated 
output VCN. 

By making the Kick FIFO large enough to hold 
a Kick for every master VCN (there will only ever 
be one current Kick per master VCN), the above 
arrangement ensures that no Kicks are ever lost 
whilst providing the desired processing elasticity to 
deal with multicast expansion. 

The detailed working of the Figure 16 arrange- 
ment is as follows. The procedure for adding an 
entry (Kick) to the FIFO 140 depends on whether 
the FIFO is currently empty or not. This is in- 
dicated by an associated empty flag 142. If the 
empty flag is set, the FIFO is empty and adding a 
new entry involves writing the new master VCN in 
the Kick to Read and Write pointers 143, 144, 
appropriately setting the multicast flag 145 in the 



entry pointed to by the Write pointer (in the present 
example, a value of one indicates a multicast con- 
nection), and resetting the empty flag 142. 

If the empty flag is not set, the FIFO 140 is not 

5 empty and adding a new entry involves two steps. 
First, the new master VCN is written to the location 
that the Write pointer currently points at. Second, 
the new master VCN is written to the Write Pointer 
and the multicast flag at the new location pointed 

10 to by the Write pointer is appropriately set. In the 
example shown in Figure 16 adding master VCN 
11 to FIFO 140 would involve writting 11 to location 
14 and then writing 11 to the Write pointer and 
setting the multicast flag in location 11 appro- 

75 priately. 

Reading the FIFO 140 will return the value in 
the Read pointer 143 together with the state of the 
multicast flag held in the location pointed to by the 
Read pointer. The Read pointer is then advanced 

20 by reading the location to which it points and 
storing the read value as the new value of the Read 
pointer. However, before this new value is written 
to the read pointer, the old entry must be changed 
to be NULL Once this is done, the new value can 

25 be written to the read Pointer. 

The FIFO 140 is empty when the value written 
to the read Pointer is NULL; in this case, the empty 
flag is set. 

A read from the FIFO 140 shown in Figure 16 

30 would return a master VCN value of 1 with an 
indication that it related to a unicast connection. 
Advancing the Read pointer would involve reading 
location 1 (giving a value of 2), writing 0 to location 
1 and finally writing 2 to the read pointer. 

35 Where a master VCN read from the FIFO re- 

lates to a unicast connection, the master VCN is 
simply output as the output VCN. However, where 
the master VCN relates to a multicast connection, 
ther! the rrvjltlcsst crcuo store "» 4^ ^ust '23 rc- 

40 rerred to for the output VCWs to be output 

Multicast groups are held as singly linked lists 
in store 141. These lists are created when a mul- 
ticast connection is set up. Expanding a Kick on a 
particular multicast master VCN simply involves 

45 initially using the master VCN to enter the correct 
list in store 141 and then following the list using a 
Multicast pointer 146 and copying each output 
VCN encountered. 

The example entries of Figure 16 show the 

so following: 

- Multicasts group set up: 3, 4, 13 

5, 6. 10, 12 

- Input sequence of master VCNs: 1, 2, 5, 8, 
14 

55 - Output sequence of output VCNs: 1, 2, 5, 6, 
10. 12, 8, 14. 
Figure 17 shows a refinement of the Figure 16 
arrangement. Because the or the first output VCN 



37 



EP 0 680 179 A1 



38 



associated with a master VCN has the same value 
as the latter, the output VCNs in a multicast group, 
other than the first output VCN, will have been 
chosen with values different from any master VCN. 
As a result, it becomes possible to arrange for the 
Kick FIFO 140 and multicast group store 141 to 
use the same block of memory, the first entry in 
each multicast group list being discarded as redun- 
dant over the corresponding master VCN entry. 
Figure 17 graphically depicts this effective merging 
of the FIFO 140 and store 141. Now when a 
multicast master VCN is read from the Kick FIFO, 
its value is output as the first output VCN of the 
corresponding multicast group and the other output 
VCNs are then output using the appropriate linked 
list. In fact, to locate this list, some appropriate 
connection must be provided; in the present exam- 
ple, this connection is made implicit simply by 
arranging that the second output VCN in every 
multicast group always has a value of one more 
than the first output VCN (that is, than the master 
VCN). The connection could be made explicit (and 
variable) by including an extra pointer associated 
with each master VCN but this is not preferred. 

In Figure 17, it will be noticed that even the 
entries belonging to the multicast group store have 
been shown as having a multicast flag field. This is 
simply because it is convenient to have all entries, 
whether belonging to the FIFO data structure 140 
or store data structure 141, of the same size. 

It may be noted that the combined structures 
140 and 141 of Figure 17 can be considered as an 
output VCN FIFO store alone, because upon each 
Kick being entered it effectively sets up the con- 
nections adding the appropriate output VCNs to the 
sequence of those awaiting output. Buffering the 
output VCNs rather than the Kicks is possible be- 
cause no per output VCN operations are required 
for making entries to the Figure 17 arrangement - 
the or,\y y£ 7 0: : tpi/± VC^ cssratlcr.o v^ose in- 
volved in syfis&cv'AQ the output VC^s iton\ ihs 
Figure 17 arrangement. 

Credit Provision 

The credit provision block 80 (Figure 8) pro- 
vides send credits to the eligibility control block 77 
in respect of output VCs that are either: 

(a) Best Effort, flow controlled; or, 

(b) Guaranteed Bandwidth. 

For case (a), the send credit reflects the 
amount of available buffer space advertised by the 
downstream node; it is the responsibility of the flow 
control block 85 to interpret the credit messages 
received from the downstream node and to inform 
the credit provision block 80 of the credit amounts 
advertised for the output VCNs concerned. 



For case (b) (Guaranteed Bandwidth VCs), the 
credit provision block 80 operates a token bucket 
rota for generating tokens (credit) at regular inter- 
vals, the average rate at which tokens are gen- 

5 erated in respect of a particular Guaranteed Band- 
width VC being set to reflect the rate at which the 
VC is allowed to send, the generated credits are 
passed to the eligibility control block 77 where they 
are placed in token buckets associated with the 

io appropriate output VCNs. When a cell in sent in 
respect of an output VCN, a credit is removed from 
the corresponding token bucket. 

The token bucket rota operated by the credit 
provision block uses a table 150 and a counter 151 

75 as shown in Figure 1 8. 

The table 150 is of fixed size (M entries) and 
contains the output VCNs which relate to Guar- 
anteed Bandwidth VCs. Associated with each out- 
put VCN is a credit increment value. 

20 The counter 151 is a modulo M counter which 

is incremented at regular intervals. After the coun- 
ter has been incremented, the output VCN and 
credit increment is read out of the table and sent to 
the eligibility control block. If the table entry is 

25 blank then no credit is sent during this interval. 

The reason for having the credit increment field 
rather than always sending a single credit is to 
avoid the need for the eligibility control block to 
have to service the token bucket rota every cell 

30 time. If, for example, thetoken bucket rota is ser- 
viced only every other cell time, then if only one 
credit could be sent at each service, the switch 
would be unable to allocate more than half of its 
output bandwidth to Guaranteed Bandwidth VCNs. 

35 Conversely, if this problem were avoided by always 
sending two credits, the accuracy of the token 
buckets would be affected. 

Generally, the credit increment field will be one 
bit wide so as to be able to Indicate w^r^e 7 ore cr 

CZ tWO CrcdiiS SilOUiO D8 Sent The field COlmu be 

made wide to allow for greater flexibility. 

The length of the table in the token bucket rota 
is determined by the resolution required in allocat- 
ing bandwidth. Typically, each table entry can be 
45 arranged to correspond to a 64Kb/s slice of band- 
width. 

The token bucket rota is set up at connection 
establishment time. If one 64Kb/s slice is required 
for a particular output VCN, the processor unit 
so must find an empty table entry and write the VCN 
to it. If more slices are required, the processor unit 
must write the output VCN into the rota several 
times spaced as evenly as possible. 

55 Eligibility Control Block 

The function of the eligibility control block 77 is 
to keep track of the send credit of output VCNs 
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that need credit to send, and to pass on to the 
scheduling block 75 those output VCNs with cells 
to send that either require and have send credit, or 
do not require such credit. 

The eligibility control block 77 maintain a cer- 
tain amount of data for each output VCN, this data 
being held in table 81 and comprising the following 
items (see Figure 19): 

- credit, which is the number of cells which the 
output VCN currently has credit to send; 

- maximum credit, which is the maximum value 
that the credit field may take; 

- the "cells flag", which when set indicates that 
the output VCN has cells in Its queue but was 
not scheduled because of lack of credit; 

- the QOS (quality of service) associated with 
the output VCNs; this will be one of: 

* GBO - Guaranteed Bandwidth with low la- 
tency, 

* GB1 - Guaranteed Bandwidth with ligher 
latency, 

* BE - Best effort; 

- the "output control flag", which when set 
indicates that a Guaranteed Bandwidth output 
VCN has a shaped output, or that a Best 
Effort output VCN is flow controlled; and, 

- the external port number. 

All of this data, except the credit and "cells 
flag" is set up at connection establishment time 
and not changed after this. 

As shown in Figure 19, the eligibility control 
block is arranged to receive input message from 
four different sources. Each input message com- 
prises an output VCN and certain information per- 
taining to that output VCN. These inputs and their 
effect on the send credit of an output VCN are as 
follows: 

1 . An output VCN from the send kickoff block 82 
signalling that at least one new ceil is available 

for ftrZ o--!5Ju! VCS. This ;r;o«; effect cr. 

the correspond!* J** credit count: 

2. An output VCN and credit increment from the 
token bucket rota of the credit provision block 
80 signalling that the output VCN's token bucket 
should have more credit placed in it. The credit 
count is increased accordingly subject to the 
maximum credit limit; 

3. An output VCN and credit amount from the 
flow control block (via the credit provision block 
80) signifying that a downstream node has ad- 
vertised this amount of credit. The correspond- 
ing credit count is set accordingly; and, 

4. An output VCN, possibly with a "more cells" 
indication, from the queuing block 63. The re- 
ceipt of the output VCN indicates that a cell has 
been sent on that output VCN so that the latter's 
credit must be decremented (unless it is zero). 
The "more cells" indication indicates that the 



VCN's queue has more cells and so should 
continue to be considered for scheduling, pro- 
vided it still has credit. 
After the eligibility control block 77 has made 
5 any required adjustment to the credit count of an 
output VCN on which it has just received an input, 
it goes on to consider whether, in view of that 
input, a message should be sent to the scheduling 
block placing the output VCN in the appropriate 
ro queue. A message will be sent to the scheduling 
block in the following circumstances: 

1. An output VCN from the send Kickoff block 
will cause a message to be sent: 

* if the credit is greater than zero, 

15 * or if the VCN is Guaranteed Bandwidth 

with an unshaped output, 

* or if the VCN is Best Effort without flow 
control; 

2. An output VCN and credit increment from the 
20 token bucket rota will cause a message to be 

sent if the "cells flag" is set indicating that the 
VCN has cells but has not previously been 
scheduled due to lack of credit; 

3. An output VCN and credit from the output 
25 flow control block will cause a message to be 

sent if the credit is now non-zero and the "cells 
flag" is set; and 

4. An output VCN and "more cells" indication 
from the queuing block will cause a message to 

30 be sent: 

* if the credit after decrementing is greater 
than zero, 

* or if the output VCN is Guaranteed Band- 
width with an unshaped output, 

35 * or if the output VCN is Best Effort without 

flow control. 

The message sent to the scheduling block 
contains the relevant external port number and 
queue number, as we!! as t^s oi??pi=* VC^ : . Obt^lr. 
cg ing Ine externa! port number just involves locking it 
up in table 81. The queue number normally cor- 
responds to the QOS of the VCN. So GBO output 
VCNs go in queue 0, GB1 output VCNs go in 
queue 1 and Best Effort output VCNs go in queue 
45 2. There is one exception to this rule: Guaranteed 
Bandwidth output VCNs which have unshaped out- 
puts and have no credit are put in queue 2 (the 
Best Effort queue). 

The final task which the eligibility control block 
50 must perform is to update the "cells flag". The 
"cells flag" indicates that an output VCN has cells 
queued but was not passed to the scheduling block 
because it did not have credit. There are two ways 
in which this can arise: 
55 - when an output VCN arrives from the send 
kickoff block and the output VCN is not 
passed on to the scheduling block because it 
has no credit; and, 
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- when an output VCN arrives from the queuing 
block with the "more cells" indication and is 
not passed on to the scheduling block be- 
cause is has no credit; 

The "cells flag" is set in these two cases. In a!l 
other cases, the "cells flag" is cleared except in 
the situation of an output VCN arriving from the 
flow control block and the output VCN not being 
passed on to the scheduling block because it has 
no credit; in this situation, the cells flag is not 
changed. 

One further point to note about the eligibility 
control block is the frequency at which it receives 
messages from each input. If the block can handle 
ail four inputs in a cell time, then there is no issue. 
However, typically, this will not be the case and, for 
example, it may only be possible to handle two 
inputs per cell time, the following considerations 
then come into play in determining which inputs 
need to be serviced in each cell time: 

- the input from the queuing block 63 must be 
dealt with every cell time because it is able 
to send cell details every cell time; 

- the token bucket rota can be designed to 
provide an output less than every cycle be- 
cause the increment size can be specified; 

- the flow control inputs will not be frequent 
compared to the cell time and can be con- 
trolled by means of a "ready" signal going 
from the eligibility control block to the flow 
control block; and, 

- the send kickoff block will be providing kicks 
at a lower rate than one per cell time, and 
even if kicks are arriving one per cell time 
there is the kick FIFO to ensure that no 
information is lost. Thus, this input can also 
be controlled by means of a "ready" signal 
and need not be read every cell time. 

In view of these considerations, where only two 
Inputs car, be nsri&efl e?.c«» ce?i ^rr.e, tr.z rota 
shown ir. figure 20 used in which tne queuing 
block inputs are serviced every eel! time, the token 
bucket rota inputs every other cell time, and the 
remaining inputs every fourth cell time. 

Scheduling block 

As already described, the task of the schedul- 
ing block 75 is to select the next output VCN to 
send on and pass this output VCN to the output 
control 69 of the queuing block 63. 

A respective queuing structure 76 is main- 
tained in the scheduling block for each external 
port, each structure comprising three FIFO queues, 
one for each priority (GBO, GB1, and BE) as illus- 
trated in Figure 9. The scheduling block on receiv- 
ing a message from the eligibility control block, 
places the output VCN contained in the message in 



the appropriate queue as indicated by the other 
information in the message. 

The scheduler 78 examines the queuing struc- 
ture 76 in accordance with the external port rota 
s 60B. Once the scheduler 78 has obtained the next 
external port number from the rota, it looks for the 
highest priority, non-empty queue in the queuing 
structure for that port and reads out the first output 
VCN from it. 

70 The external output-port rota 60B in the sched- 

uling block 75 is essentially the same as the rota 
60A associated with the master VCN lookup block 
61 (assuming that the externa! input and output 
ports are paired). However, the output port rota 

75 60B uses inputs from the monitor units 44 of the 
adapter cards to take account of when the output 
FIFO 42 has exceeded its one-cell threshold. In 
particular, the rota 60B prevents scheduling on an 
external output port whose FIFO has exceeded its 

20 threshold by outputting a NULL port number in the 
corresponding scheduler time slot until the FIFO 
empties to below the threshold. 

The data structures which implement the FIFO 
queues in the scheduling block are similar to those 

25 used in the multicast expander 83. These efficient 
structures can be used because it is guaranteed 
that output VCNs can only make one appearance 
at any one time in a scheduling-block queue. In- 
deed, an output VCN will only be in at most one 

30 queue. As a result, it is possible to overlay all of 
the FIFO queues in one small block of memory 
while still being sure that none of the FIFO queues 
will ever become full. 

The data structures used to implement the 

35 scheduling FIFO queues are shown in Figure 21 
together with sample data for the queues relating to 
external port 0. Also shown in a dashed box in this 
Figure, is a more conventional FIFO representation 
of the example data. 

40 Each FiFO queue {for example, queue ror? 0, 

GBO) is stored as a singly linked list with a head 
pointer 161, a tail pointer 162, and an empty flag 
163. These pointers reference a block of memory 
big enough to hold all the possible output VCNs. 

45 Data is read from and written to each FIFO queue 
in the same way as the kick FIFO described above. 

After each read from a FIFO queue, the tail 
pointer 162 is tested to see whether the FIFO 
queue has gone empty. If the tail pointer is NULL, 

so then the FIFO is empty and the empty flag 163 is 
set. The flag will remain set until a write occurs to 
that FIFO queue. 

In Figure 21, each empty flag is shown 
grouped with the corresponding head and tail 

55 pointers. However, in practice, the empty flag 163 
of all queues associated with same external port 
will be grouped together so that they can be read 
in one operation; this then makes it easy for the 
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scheduler 78 to determine which queue should be 
read for the current externa! port in rota 60B. 

Output Header Generation Block 

After the scheduler 78 has taken an output 
VCN from a port queue, it passes this output VCN 
to the output control 69 of the cell-details queuing 
block 63 which retrieves the cell-details for the 
next-to-be-sent cell on that output VCN. These cell 
details and the output VCN are passed to the 
output header generation block 64 whose task it is 
to generate the header for the cell to be sent. The 
first step in generating a header is to use the 
output VCN to look up the output VPI and VCI in a 
table 165 which stores this information. This table 
165 is set up at connection establishment. 

The VPI and VCI are then combined with the 
cell type and AAL5 EOP bit from the cell-details 
information passed to block 64 to form the first four 
bytes of the cell header. These are then passed to 
the fabric 30 along with the address of the cell 
body. 

It should be noted that the header error check 
is not calculated at this point. Instead, this calcula- 
tion is done in the relevant adapter card. 

Variants 

It will be appreciated that the above-described 
functional blocks can be implemented in a variety 
of ways though generally hardware implementa- 
tions will be preferred for speed of processing. 

It will further be appreciated that the described 
functionality may be divided between blocks in 
various ways and generally the boundaries of these 
blocks are arbitrary. Thus, for example, and with 
reference to Figure 22, the functionality used to 
generate the "Kicks" supplied to the multicast ex- 
«}?-de 7 £S czn ccr.ciccc^ ;g .eslcie v\e sere 
control raiher than :n tfte queuing b-ock. :n 
particular, this Kick-generating functionality cculd 
be considered part of the send Kickoff block 82 
(see Kick generation block 170 in Figure 22). This 
Kick generation block effectively receives a\\ mas- 
ter VCNs of incoming ceils but only generates a 
kick upon the queue data 171 held in queue block 
63 (that is, the producer and consumer pointers, 
the empty flags and stop bits) indicating that the 
appropriate conditions (already detaild) are present. 
Similarly, the mechanism for recycling output 
VCNs can be considered as queue-data responsive 
functionality contained in the send control path 
rather than being embedded in the queuing block 
63 (see recycling block 172 in Figure 22). Again, 
the output VCNs output by the scheduler 78 may 
be viewed as being fed to a cell output mecha- 
nism, including the block 165, that then uses the 



queuing block 63 to provide the eel) body address. 
Numerous other variations in functional block 
boundaries can be envisioned without fundamen- 
tally altering the principles of operation of the de- 

5 scribed switch. 

More substantive variations are also possible. 
In particular, the mechanism for injecting output 
VCNs into the eligibility control block from the send 
Kickoff 82 can be varied as will now be explained 

io with reference to Figure 23. this Figure being gen- 
erally drawn with the same functional block bound- 
aries as in Figure 22. The general principle behind 
the output-VCN injection mechanism of Figure 23 
is that the multicast expander 82 is made respon- 

75 sive to every new cell arrival as indicated by each 
new master VCN generated by block 61; now, on 
receiving a Kick on a particular master VCN, the 
multicast expander will only queue for injection 
those associated output VCNs that are not already 

20 in the scheduling loop (that is, held in the eligibility 
control block 77, queued in the scheduling block 
75, or in the process of being recycled by the 
recycling means 172). 

An obvious benefit of this arrangement is that it 

25 is no longer necessary to utilise empty flags and 
stop bits to set up and determine the conditions 
upon which a Kick is sent to the multicast ex- 
pander. As a result, the operations of the input and 
output controls 66 and 69 of the queuing block 63 

30 can be simplified and the Kick generation block 
170 of Figure 22 removed entirely- However, to 
achieve this benefit, it is necessary to arrange for 
the multicast expander 83 to know which output 
VCNs are not in the scheduling loop. Of course, 

35 prior to receipt of the first master VCN on a newly 
set up connection, no output VCNs are in the 
scheduling loop and so initially the multicast ex- 
pander can be set with all the output VCNs for that 
master VCN ready to be Injected :r.tc *to sc^edut- 

cz ing loou. Furthermore, once the output VCNs asso- 
ciated with a particular master VCN have been 
injected into the scheduling loop, it becomes easy 
for the recycling means 172 to notify the multicast 
expander when an output VCN is about to be 

<3 droppe6 from the loop. The recycling means sim- 
ply passes an output VCN back to the multicast 
expander rather than to the eligibility control block 
when the recycling means determines that the out- 
put queue 70 for that output VCN is empty (in fact, 

so the output VCN will still also be passed to the 
eligibility control block for credit setting purposes, 
but the "more cells" flag will not be set). 

The multicast expander 83 then only has to 
keep a list for each master VCN of which asso- 

55 dated output VCNs are not in the scheduling loop; 
upon receipt of a master VCN from block 61, the 
multicast expander simply places the appropriate 
list of output VCNs into an output FIFO for injection 
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by output circuit 84 into the eligibility control block 
77. 

Among other possible variants are: 

- permitting multiple occurences of the output 
VCNs in the scheduling means (the multicast 
expander always injecting the full set of out- 
put identifiers associated with a master VCN 
upon the receipt of a corresponding cell; in 
this case, no recycling means would be re- 
quired); 

- storing the cell bodies directly in linked lists 
rather than separately storing the cell-body 
sequencing data in the queuing block. 

For practical reasons, neither of these possible 
variants is preferred. 

It will be appreciated that many of the concepts 
of the controller described above can be applied to 
packet-based systems having variable length pack- 
ets as well as to systems handling cells (fixed- 
length packets). 

Claims 

1. Apparatus for receiving at least one input 
stream of packets each having a packet body 
and multicasting this stream as a plurality of 
output streams of packets by copying across 
the packet bodies of the packets of the input 
stream into packets of the output streams, said 
apparatus comprising: 

- input means for receiving packets and 
determining to which input stream each 
packet belongs, 

- storage means for storing both the pack- 
et bodies of the packets received by the 
input means and a respective sequence 
data set for each input stream, each se- 
quence data set serving to order the 
packet bodies received for the corre- 
spond??^ ir?pLf; etrc™. \r. zvZz/ of >r~ca^?l 
ths storage means :nc:ud;r;g an iftpui 
control which upon a new packet body 
being stored, updates the sequence data 
set of the input stream to which the 
packet belongs as determined by said 
input means, and an output control for 
maintaining for each output stream a se- 
quence position indicator referencing into 
the sequence data set of the correspond- 
ing input stream to indicate the next 
packet body to be sent on the output 
stream concerned, and 

- output means for scheduling output on 
said output streams for communicating 
with the output control of the storage 
means to identify the packet body next 
to be output on the currently-scheduled 
output stream, and for retrieving and out- 



putting the identified packet body on the 
scheduled output stream. 

2. Apparatus according to claim 1, wherein said 
5 packet bodies and sequence data sets are 

separately held in said storage means, each 
sequence data set comprising a linked list of 
packet-details entries each with a packet-body 
pointer to a respective corresponding packet 

to body and a next-entry pointer to the next en- 

try, if any, in the same list; said input control, 
upon a new packet body being stored, setting 
up a corresponding packet-details entry in the 
appropriate linked list, this setting up including 

75 setting the packet-body pointer of this entry to 

point to the newly stored packet body; each 
said sequence position indicator maintained by 
said output control for each output stream, 
pointing to the packet-details entry for the 

20 packet body next to be sent for the output 

stream concerned. 

3. Apparatus according to claim 2, wherein each 
said packet-details entry has a multicast count 

25 item which is set by said input control, upon 

setting up of the entry, to the value of the 
number of output streams to be multicast from 
the input stream associated with the linked list 
of which the packet-details entry is a part, said 

30 output control decrementing the count item of 

a packet-details entry each time said output 
means outputs the corresponding packet body 
until the packet body has been sent on all 
relevant output streams whereupon the output 

35 control causes the removal of the entry from 

the corresponding linked list. 

4. Apparatus according to claim 2, wherein each 
Input stream is identified >n the ecsaratus by £ 

<o corresponding input identifier, said input 

means providing this identifier for each new 
packet received thereby to indicate to which 
input stream the packet belongs, said input 
control of the storage means keeping respec- 
ts tive list pointers pointing to the tail of each said 
list and maintaining an association between 
each input identifier and the list pointer that 
points to the linked list associated with the 
input stream identified by the input identifier. 

50 

5. Apparatus according to claim 4, wherein each 
linked list has a tail entry devoid of packet- 
related information, the said list pointer kept by 
the input control pointing to the tail entry of the 

55 corresponding linked list; and the input control, 

upon a new packet body being stored, adding 
a new tail entry to the relevant linked list and 
using the former tail entry of that list as the 
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packet-details entry for the new packet body, 
the control means adjusting the list pointer for 
that list accordingly. 

6. Apparatus according to claim 1, wherein each 5 
output stream is identified in the apparatus by 

a corresponding output identifier, the output 
means including send-control means for effec- 
ting output scheduling of said output streams 
on the basis of said output identifiers and w 
indicating the next scheduled output stream by 
outputting the corresponding output identifier; 
the output control of the storage means main- 
taining an association between each output 
identifier and the sequence position indicator 15 
for the output stream identified by said output 
identifier, and being operative when supplied 
with a said output identifier by the output 
means, to utilise said association to retrieve 
the packet-body pointer for the next packet 20 
body to be output on the output stream con- 
cerned. 

7. Apparatus according to claim 6, wherein said 
send-control means comprises: 25 

- scheduling means for effecting said out- 
put scheduling on the basis of said out- 
put identifiers, and for indicating the next 
scheduled output stream by outputting 

the corresponding output identifier, there- 30 
by removing it from the scheduling 
means, and, 

- injection means for injecting output iden- 
tifiers into the scheduling means, the in- 
jection means being responsive to the 35 
receipt by said input means of at least 
certain of said packets newly received 
thereat to inject into the scheduling 
means the output identifiers of at least 
serr.s of tnc output etrearr.s associate; to 
wiih the input streams to which said cer- 
tain of said packets belong; 

said send-control means being such that a said 
output identifier can be present only once at 
any one time in said scheduling means, and 45 
the send-control means further comprising re- 
cycling means responsive to the state of the 
sequence data set relevant the output identifier 
last output by said scheduling means, to return 
that output identifier to the scheduling means so 
in the event that said sequence data set in- 
dicates there is at least one further packet 
body available for sending on the output 
stream concerned. 



9. Apparatus according to claim 1, wherein: 

- said packet bodies are each stored only 
once in said storage means, 

- said sequence data sets together have a 
respective entry for each packet body, 
each entry including a pointer to the cor- 
responding packet body, and each entry 
being present only once in said se- 
quence data sets taken together, and, 

- each output stream is identified in the 
apparatus by a respective output iden- 
tifier and said output means includes 
send-control means for effecting output 
scheduling on the basis of said output 
identifiers, each said identifier being ac- 
tively present no more than once at any 
one time in said send-control means. 



& Apparatus according to claim 1, wherein said 
packets are ATM cells. 
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